<@U3T6LDWTD> I have an issue with `[1,2,3]` being ...

# language-proposals

[jkbbwr]

@benleggiero I have an issue with [1,2,3] being both List<Int> and Set<Int> and Array<Int> depending on context.

[karelpeeters]

I'm sorry for asking yet again but where does this come from? There was a discussion about this a couple of weeks (months?) ago in this channel.

[jkbbwr]

Coming back after some time out, missed any discussion.

[ilya.gorbunov]

I suppose this is about the collection literals proposal. Perhaps it would be better to provide the context for the discussion: https://github.com/Kotlin/KEEP/issues/113

[benleggiero]

Thanks for bringing this up! What's your qualm?

[poohbar]

I just think it is overall a terrible idea for many reasons and I hope it never makes it into a language. Sorry, Ben.

[dave08]

Until you get tired of the listOf clutter @poohbar... When you need to use it often enough, it gets very tempting to let go of the other reasons. I have tons when working with jsonRpc apis and microservices... I also don't like extra stuff 😉

[poohbar]

If it pains you so much create your own shortcuts:

fun l(...) = listOf(...)

[benleggiero]

@poohbar I actually did trials with a syntax that went something like that. However, since Kotlin cannot yet compile bytecode that disambiguates methods by their return type, it was even worse, like Systems Hungarian:

val foo: Array = a[1, 2, 3]
val bar: List = l[1, 2, 3]
val baz: MutableList = ml[1, 2, 3]
val hoge: Set = s[1, 2, 3]
val qux: MutableSet = ms[1, 2, 3]
// etc.

Also curious, have you ever worked with a language that can do this, like Swift?

[poohbar]

I worked with Clojure that had collection literals but it was not trying to recreate Java collections. Clojure has its own collection implementations so it made sense.

[benleggiero]

Could you elaborate? And, would Kotlin having its own collection implementations solve your qualm?

[dave08]

I've worked with php and python, and as much as I hate them and prefer Kotlin mich more, I think this is a nice proposal... I agree that to prevent "polluting" the language is a valid argument, but here I think clarity of code comes first.

The sequence/list/set inference is the same as any inferred generics one could be using...

[jkbbwr]

@benleggiero My main problem is its not clear at first glance which data strucutre it is.
If I read the sentence listOf(mapOf(1 to setOf(1))) it reads really easily. Now take a look at [{1: [1]}]
My eyes need to keep jumping from definition to type to definition

[jkbbwr]

You gain little and add more ambiguity

[dave08]

I think any language feature can be abused and cause hard to read code... just try Kodein DI vs. Dagger2, in dagger all the types you're passing into constructors is explicit, whereas Kodein uses Kotlin's type inference, and you pass instance() to everything... the gain of conciseness is worth the loss of being explicit sometimes. @jkbbwr

[benleggiero]

Exactly. You can totally reduce readability of code with plenty of existing Kotlin features. This simply aims to reduce boilerplate and get from "I want a list" to "I have a list" much faster, without having to worry about exactly what type a library call will return. Even in Swift, after which I modeled this proposal, you eventually sometimes have to use the actual type names. For that example, in Swift, I'd do [[1 : Set(1)]], and in Kotlin: [{1 : setOf(1)}]

[jkbbwr]

Sure but why add symbols when we have words?

[jkbbwr]

this change doesn't seem to gain anything

[benleggiero]

The same reason why this:

class Foo() {
    fun bar() = baz
}

is better than this:

BEGIN CLASS Foo
    FUNCTION bar GIVES Baz
        RETURN baz
    END FUNCTION bar
END CLASS Foo

[jkbbwr]

There is a line between verbose and reasonable.
I think too much information is lost with collection literals.

[dave08]

When that happens, you don't have to use them, which is @benleggiero's point, but when the intention is clear (which it is in very many cases), I think it makes the code much cleaner @jkbbwr

[jkbbwr]

There should be one way to do things and that way should be obvious. Adding syntax adds ambiguity.

[dave08]

Type inference also causes ambiguity...

[benleggiero]

Kotlin strikes a balance between ambiguity and reduced boilerplate. This proposed syntax is optional, and just as easy to tell the type as all the other places it's inferred since version 0.0.1

[jkbbwr]

But now there are two ways of creating collections, this will cause confusion to people learning the language and will be less "single path"

[benleggiero]

That's why my proposal says that those functions which can be completely replaced with the collection literal syntax be deprecated: https://github.com/BenLeggiero/KEEP/blob/collection-literals/proposals/collection-literals.md#changes-to-stdlib

[jkbbwr]

But thats making an opinionated thus long term breaking change.

[jkbbwr]

(in my humble opinion) It just feels like adding something "because it would be nice" more than a pressing usecase. Shortening what you type is not a practical reason considering we have auto complete.

[benleggiero]

There are plenty of arguments outlined in my proposal. Obviously, my mindset isn't shared with the community, so I'm no longer pushing it.
Maybe someday I'll fork Kotlin and try to implement it myself 😛