Actually this discussion conflates two issues which are actually separate: the syntax for using arrays in annotations and the syntax for collection literals.
Inside annotations, arrays are a special case because there is a very restricted set of data types allowed for use as annotation parameters. It’s obvious that the current situation with arrays in annotations in Kotlin is significantly more ugly than Java, because array parameters are used commonly and require using arrayOf() which is not required in Java. This is what KT-11235 is talking about. Addressing this issue may, or may not, require introducing some kind of syntax for collection literals.
Outside of annotations, arrays are most definitely not a special case and we’re most definitely not going to introduce a syntax which will allow you to create only arrays but not other kinds of collections.
You say that you’re asking for something which is very very small - but it is not, because there’s a very limited amount of characters that can be used as part of the language syntax without making the language more ugly. If we use the [1, 2, 3] syntax for array literals as Java does, it makes this syntax permanently unavailable for other constructs which we may consider more important to include in the language (the most obvious one is literals for other kinds of collections such as lists).
What about a combinational character like e.g. F#, again, there are numerous ideas one can throw.
Is the JetBrains team willing to do the same as Java where annotations are concerned without special array syntax, or are you contemplating array syntax delimitation, or none at all.
Without special syntax: method = arrayOf(RequestMethod.GET …)
With array syntax: method = {| RequestMethod.Get |}
None at all: method = RequestMethod.GET
I would try to hit 2 flies in 1 swat and keep the array short and consistent- (middle option). But that clearly is not likeable by the sounds of it.
Again, this is not a show stopper. I am living with arrayOf currently. Do I like it, no, will I get used to it to the point of second nature - yes. Does it feel awkward in the light of how Kotlin handles other things - purely subjective - yes.
I did a similar proposal for data classes, arrays, lists and maps to look Kotlin a type checked JSON, useful -in my opinion- for REST, no-SQL and builders (without intermediary functions).
Both may be interesting features but not key featuress, for now.
I understand the bigger audience’s reluctance as technologies that are here today… may be outdated tomorrow (while the legacy must remain in the language)- so staying true to the core is important. In my ‘uneducated’ opinion however - to strengthen your point - is that many mainstream languages are incorporating “scripting language” notation and technologies. It is a tough one…
My liking exactly… meaning with an implicit cast it could be var a = . If you judge by the thread, then you probably will come to the conclusion that arrays are, for many Kotlin developers, outlandish by its use. I however, in dealing with almost every 3rd party Java library repeating arrayOf sometime many times in one line of code (which just is awkward). Lost the battle, lost the war. It still remains one of my biggest syntactical pains with the language; especially but not limited to annotations; keeping in mind I have been using Kotlin for 7 more months since I started the thread.
yes, arrayOf() can stays as a supported method but main trend should be . And if we’ll going deeper - It’s very inconvenient to use something like this = arrayOf(arrayOf(arrayOf(
kotlin compiler is open source so one could fork the project and try to add the support of something like “var a:Array = ” in kotlin compiler by oneself))) i suppose it is not simple as we think, even adding a ternary operator costs time
It’s not about the difficulty of implementing this into a language, it’s about making the right decision. It will be very hard to change this when it’s released. Like yole pointed out in this same thread:
again, one could fork kotlin compiler, implement the feature and show it as a proof-of-concept, so it is up to the community to merge the pull request or not))
Implementing this in some form, e.g. your/marciodel suggestion, is not the hard part. The hard part is making a proper language design decision that makes it suitable for more then one type of data structure. You might want to support Lists, Sets and Arrays. With the latter (Arrays) being the least interesting one outside of annotations. That’s why I quoted yole which shows the direction the people at Jetbrains are looking at, or at least the concerns that need to be addressed.
Actually the decisions to merge pull requests for the Kotlin compiler are currently made by the Kotlin team, not by the community, and I can say for sure that the Kotlin team is not going to merge a pull request adding support for array literals using the Java syntax.
I sat for about 30 minutes on a wire wobbling between reply and not (for I have made my point several times, a big meal of it). Can I ask you a leading question… who do JetBrains see to be primary target market for Kotlin. And please, if possible, can you be specific. Keep in mind you reside on a technology (Java/JVM) that already has set some bounds to your opportunities.
In other words - what market sector(s) doing what is going to be using Kotlin most often in 3 years time.
PS: Open Source from a foundational tool POV to me is irrelevant. Forking Kotlin in my or any environment I have ever worked in will be a train wreck in slo w m o t i o n. There are simply so many reasons for it that I won’t even try to entertain listing any.
I’m not sure how your question is connected to the topic of this discussion. With Kotlin, we’re aiming for a very broad audience, and with our JavaScript and native efforts, we are not constrained by the bounds of Java/JVM.
Getting closer to the topic of the thread, we do plan to support the possibility to use arrays in annotations using a more concise syntax that arrayOf(), and we do plan to support a dedicated syntax for collection literals outside of annotations (not restricted to arrays, and possibly not supporting arrays at all). My only point was that sending a pull request implementing a version of the syntax with which the team explicitly disagrees is not a good way to move this issue forward.
While one may agree or disagree with the Kotlin team on specific issues the most important reason is to have a consistent design to the language. This can work with input and suggestions or even well argued disagreements, but not with popular vote. Committee design may work as visible with C++ but it does come with heavy burdens in either overheads and lack of responsiveness (appropriate for languages with more maturity and need for compatibility) or in burdens of misdesigns.
@yole - While I respect and fully understand all reasons - keeping in mind that most arguments are made several times over, my question to the Kotlin designers and JetBrains Team is a very simple one.
The Kotlin stack of technologies relies heavily on a Java stack. Even though some clever people are designing Kotlin specific api’s that surpasses the Java counterparts in syntactical sugar etc - it is clear to me that Kotlin developers will still be reliant on tried and tested Java based technologies for quite some time to come.
Now I unfortunately have to jump to a second point before concluding. Who is using Kotlin in what capacity? This will give you better direction as to what language features are really important. I do understand it that you don’t want to bloat the language with API features - that is not what I am talking about - but there is effect if you consider the first point of which/where in most of these libraries, arrays still play a huge role.
In all honesty - I have buried the issue until it resurfaced - and many months later the lack of a short form array still is a pain to me. And like said before - this is mostly due to the fact that the rest of the syntax is super short, concise, even pretty; which makes arrayOf stand out like a sore thumb.