6 ms·

Does anyone else think the Kotlin syntax for array literals is super ugly: val shoppingList = arrayOf("catfish", "water", "tulips", "blue paint") What is

Does anyone else think the Kotlin syntax for array literals is super ugly: val shoppingList = arrayOf("catfish", "water", "tulips", "blue paint") What is wrong with square bracket syntax? (rant over). EDIT: I suppose it's consistent with other syntax e.g. listOf() etc.

pmontra 9y ago
I agree, it leaves a bad taste in the mouth. It's even worse than old PHP's array(). I'll pick short forms all the time: lists with (), dictionaries/hashes with {}.
- ansible 9y ago
  Python does this too, and I dislike it slightly. I'd prefer uniform syntax for collections, such as in Lua or golang.
masklinn 9y ago
> Does anyone else think the Kotlin syntax for array literals is super ugly: Well yeah, except it's really that Kotlin does not have array literals at all, arrayOf is just a variable-arity function.
- billyjobob 9y ago
  I guess they think they are cool for being able to provide this feature through a library function rather than a language construct, but someone should tell them they really need to add some syntactic sugar that transparently invokes arrayOf while looking nicer.
  - mikeash 9y ago
    It's worth nothing that Swift literals are mostly library constructs as well. Any type conforming to ArrayLiteralConvertible can be instantiated using [...] syntax, for example. All other literal types (integers, floats, strings, dictionaries, etc.) have their own corresponding protocols you can implement. The only thing that's special for types like Array, Int, or String is that the compiler will automatically infer those types for a literal if there's nothing that indicates otherwise. For example: let x = [1, 2, 3] // produces Array let y: MyType = [1, 2, 3] // produces MyType f([1, 2, 3]) // produces whatever type f() takes
ungzd 9y ago
Plain Java has similar function too: https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList-T...- https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.h...
jorgemf 9y ago
It is also because [] is an operator that you can override. I think because of this it would make more difficult to use it also to create arrays. It is more ugly for arrays but much more helpful for other things. And it also make sense with the lists as you said.
bobbyi_settv 9y ago
I've had the same issue with Scala. It goes out of its way to provide every syntax convenience that has ever existed--pattern matching, custom string interpolation, literal syntax for tuples, optional parens on method calls--- and then requires Maps and Seqs to be created with syntax like val shoppingList = Seq("catfish", "water", "tulips", "blue paint")
- saosebastiao 9y ago
  I personally like that about scala. If I decide an IndexedSeq is better than my original choice of List, it is just a rename, not a syntax change.
foobarbazetc 9y ago
First thing I noticed. The map entry syntax: "Foo" to "Bar" Is also nonsensical. What's wrong with ':'?
- ptx 9y ago
  It's because to is an infix extension method, whereas : is not a valid identifier name (and so can't be used as the method name) and you can't define arbitrary operators like in C++ and Scala. The to method constructs a Pair object from its arguments, so "Foo" to "Bar" is just a prettier way of writing: Pair("Foo", "Bar") The mapOf function (which is just a normal function) takes a variable number of Pair objects as parameters.
always_good 9y ago
It's not pretty, but it makes sense so that you actually think about whether you need an array vs list vs ? instead of just going for whatever datastructure [] is going to give you because it's most convenient. In practice, it's something I stopped caring about within the first hour. Then again, mikeash's comment pitches a more interesting idea: [] as generic collection literal syntax that depends on inference / annotation to pick a concrete implementation. Best of both worlds. I'd just remove the Array default.

pmontra 9y ago

I agree, it leaves a bad taste in the mouth. It's even worse than old PHP's array(). I'll pick short forms all the time: lists with (), dictionaries/hashes with {}.

ansible 9y ago
Python does this too, and I dislike it slightly. I'd prefer uniform syntax for collections, such as in Lua or golang.

masklinn 9y ago

> Does anyone else think the Kotlin syntax for array literals is super ugly: Well yeah, except it's really that Kotlin does not have array literals at all, arrayOf is just a variable-arity function.

billyjobob 9y ago
I guess they think they are cool for being able to provide this feature through a library function rather than a language construct, but someone should tell them they really need to add some syntactic sugar that transparently invokes arrayOf while looking nicer.
- mikeash 9y ago
  It's worth nothing that Swift literals are mostly library constructs as well. Any type conforming to ArrayLiteralConvertible can be instantiated using [...] syntax, for example. All other literal types (integers, floats, strings, dictionaries, etc.) have their own corresponding protocols you can implement. The only thing that's special for types like Array, Int, or String is that the compiler will automatically infer those types for a literal if there's nothing that indicates otherwise. For example: let x = [1, 2, 3] // produces Array let y: MyType = [1, 2, 3] // produces MyType f([1, 2, 3]) // produces whatever type f() takes

ungzd 9y ago

Plain Java has similar function too: https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#asList-T...- https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.h...

jorgemf 9y ago

It is also because [] is an operator that you can override. I think because of this it would make more difficult to use it also to create arrays. It is more ugly for arrays but much more helpful for other things. And it also make sense with the lists as you said.

bobbyi_settv 9y ago

I've had the same issue with Scala. It goes out of its way to provide every syntax convenience that has ever existed--pattern matching, custom string interpolation, literal syntax for tuples, optional parens on method calls--- and then requires Maps and Seqs to be created with syntax like val shoppingList = Seq("catfish", "water", "tulips", "blue paint")

saosebastiao 9y ago
I personally like that about scala. If I decide an IndexedSeq is better than my original choice of List, it is just a rename, not a syntax change.

foobarbazetc 9y ago

First thing I noticed. The map entry syntax: "Foo" to "Bar" Is also nonsensical. What's wrong with ':'?

ptx 9y ago
It's because to is an infix extension method, whereas : is not a valid identifier name (and so can't be used as the method name) and you can't define arbitrary operators like in C++ and Scala. The to method constructs a Pair object from its arguments, so "Foo" to "Bar" is just a prettier way of writing: Pair("Foo", "Bar") The mapOf function (which is just a normal function) takes a variable number of Pair objects as parameters.

always_good 9y ago

It's not pretty, but it makes sense so that you actually think about whether you need an array vs list vs ? instead of just going for whatever datastructure [] is going to give you because it's most convenient. In practice, it's something I stopped caring about within the first hour. Then again, mikeash's comment pitches a more interesting idea: [] as generic collection literal syntax that depends on inference / annotation to pick a concrete implementation. Best of both worlds. I'd just remove the Array default.