arrayOf unnatural

You should really learn to use a different tone of voice. Your way of communicating doesn’t avoid thoughtless opinions, it simply avoids you.

Voting is just a way to get some attention to the issue. It doesn’t have any decisive meaning. Arguments are needed for language features, both opposing and proposing. And that’s what people in this thread trying to do: getting the arguments out there for why this is both a good and a bad proposal. Maybe there are some arguments that the guys and girls at Jetbrains have overlooked. So don’t be offended if someone doesn’t blindly accepts your position, it doesn’t even mean that someone disagrees with you. So it’s not at all about convincing people.

So about the topic of arguments you make a fair point that other mainstream languages have this feature, so I most certainly agree that it can help adaptation of Kotlin as it will be a familiar construct for developers. However familiarity is not something that may be a decisive argument. There was a time when every language had a goto statement and was considered a necessary construct. Now we can do without.

Oh come on @mplatvoet - please

Every opposing view i have answered with good examples and questions into what you think is suggested. I am a working man - working for myself - for every minute wasted I PAY FOR MYSELF - so my time is precious - I don’t get into the threads for the sake of having an opinion - I go in there to get something. So answering and debating something to this extent is not easy for me.
The fact that there is no counter argument coming back on most of these issues is not due to the tone of voice - it is due to the fact that the line of reasoning is killed off.

So if you lose an argument - don’t be offended - simple as that. Cheers.

Also… please state one place where I offended you personally - instead of giving alternative reasoning to your argument?

On the contrary - I gave you a compliment about your reified example - which sadly does not work with annotations - which to me yields that you are the one becoming personal.

Like I said about 15 posts ago. I was willing to rest it.

You did not offend me. It’s just that your tone of voice makes it harder to react to the actual arguments in your posts, yet it makes it far easier to just interpret them as none constructive. You seem to think of all this in terms trying to win arguments. It’s no competition, we’re not looking for the best debater. Like I said it’s just about getting as much arguments out there, both proposing and opposing.

So what we’ve got right now is:

  • familiar syntax
  • better interoperability with annotations
  • readability


  • new syntax, parser/language complexity
  • harder to type in other keyboard layouts

other remarks

  • is this Array only?
  • is this mainly an issue for annotations?
  • should special syntax be available to every collection type?
  • what syntax should be used?

A probably missed some arguments or remarks so feel free to add.

1 Like

Ok. Then I probably need a bit of education on the pace of this type of thread. The usual threads you have to make your point thick and fast while teaching somebody to declare an array while still having to defend your argument from the same person; who has had a smarter idea :slight_smile:

You summed it up nicely.

Proposing… 100% agreed
Opposing… The thread has lifted out these issues nicely. You kind of never can be good for everybody on the keyboard layout however.
Other Remarks:

  • Array only - yes in my mind - opening this conversation towards other types will make this discussion exponentially more difficult. (Maybe another thread needed)
  • Annotation - best value there quickest - BUT the implementation may lead to array inconsistencies. Hence the reason why I tackled it from an array point of view rather than an annotation pov. This is the case for Java. There is inconsistency between declaring an array and setting an array annotation parameter. This Java “smartness” is also one of the big complaints and reasons why many newcomers struggle to adopt Kotlin (as they never knew it was an array to start off with). For me it is not about that - even though I can understand the frustration.

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).


Hi @yole ,

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.


Just BTW. Another place where I use arrays a lot is Spring JDBC.

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.

My 2 cents


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…

Sorry if it’s a necro but I’m for
var a:Array=[]

Hi Psijic,

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(

Xtend list and set + map literal use #[] and #{} . What about using this way?

Java: String[] Whatever = {“A”, “B”};
C#: string[] Whatever = {“A”, “B”};
C++: int foo[] = { 10, 20, 30 };

Xtend : var String[] Whatever = #[“A”, “B”] // transpiled to new String[]{“A”,“B”}

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:

actually, it is:

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))

Again, since you’re keep missing the point:

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.