I don't think it'd be a bad thing, but I don't feel like it's so bad to write

listOf

before the literal

@kevinmost you can still use plain getter method and suppress warning in inspection settings

at first I went "what is an O3 country?", though

I do agree though that most code is way too full of collection calisthenics..

I don’t like special collection literals for just list and map. It’s not Kotlin style, I mean you can’t DSLize it.

yeah, the more I think about it, I'd rather have it be explicit. Sets are gonna be weird. Are people gonna do

setOf(3, 4, 5)

still, or will they be tempted to do

[3, 4, 5].toSet()

which would be another allocation?

I hope that if we get some kind of collection literals, that they are extensible in some way, but I don’t know what that would look like.

It doesn’t read any better out of context

object L {
   operator fun <T> get(vararg values : T) = values.toList()
}

Not very bad by itself 🙂

Just do it like the great dead Io language and have [] be syntactig sugar for the .squareBrackets() method. You could statically import a fun squareBrackets = listOf and do things like map["someKey"] like you can in Javascript.

(Disclaimer: That wasn't a serious suggestion. While that's fun for single-player languages I would not want it in a serious language. Not having literals is fine)

does GDSL itself have javadoc in intellij? having some difficulty getting started writing it

GDSL? Do you mean #gradle kotlin script?

@orangy hopefully to give some context - im building a library for Jenkins global pipeline libraries (https://github.com/jenkinsci/workflow-cps-global-lib-plugin) for consumers of Jenkins Pipelines. Consumers will have a Groovy

Jenkinsfile

in the root of their repository, and I would like to give them something to give them IDE assistance when they consume our library without having to have them install a plugin (like this one https://github.com/oliverlockwood/jenkinsfile-idea-plugin). Most of our users use IntelliJ and Gradle, so I was trying to figure out some of solution around that. What I thought I could do, (stemming from my question above) was to write what I believe are called GDSL scripts (looking at https://confluence.jetbrains.com/display/GRVY/Scripting+IDE+for+DSL+awareness) for consumers of my library, but im definitely open to other suggestions.

Ah, I see, it’s not about Kotlin at all, it’s about Groovy. I don’t think there is much help here, may be #gradle citizens can help

hah yeah not about kotlin at all, figured i would toss it up in the #random channel to maybe get tossed somewhere else like a forum or something in the right direction

@orangy @evanchooly @avolkmann @Ruckus I actually blogged about using Kotlin for Data Science, and Hadi is shooting a Talking Kotlin episode with me in April about it. I've used it in a number of projects, everything from data wrangling to modeling, and I prefer it heavily over Python. The only thing it is weaker in is charting, data science libraries, etc. But the language and stdlib alone does an incredible amount of work with little effort. I'm happy to see more discussion on Kotlin for Data Science popping up in pockets across the web. It'd be swell to have it take off so the community can make libraries for that purpose. http://tomstechnicalblog.blogspot.com/2016/10/kotlin-for-data-science.html?m=1

Thank you everyone for your reasons for wanting collection literals in K !

I can't help to notice that most of the responses were "we like it, but it is a low priority".

Still I assume that there are a significant number of devs who would seriously want the collection literals implemented - at least that is what yesterday pools suggest

Could you describe your position + motivation for wanting collection literals (it is a high priority feature for you)?

The benefit is less tangible perhaps, but I feel it could help accelerate adoption, when newcomers see that, yes, Kotlin supports modern collection syntax too.

…and with greater adoption comes other contributions and benefits. K

One aspect of Swift’s collection literal implementation that I particularly appreciate; is that [a,b,c] can be coerced to either Array or Set.

I think this should be reproduced in Kotlin too: sometimes Sets get overlooked by developers, but they often fit the character of the data better than an Array, and we should not forget first-class support for them where it is practical.

The same point extends to other collection types: allow the collection literals to be coerced to many/all collection types.

I'm used to [a,b,c] and {a:b} from Dart and JS being list and map. It's a nice to have and eases the transition for devs coming from other languages. listOf and mapOf felt unintuitive when I just started with Kotlin and I kept writing [...] every time i need a list. 8 months later and it doesn't matter as much since I got used to lisOf and mapOf. If you do implement it, then you would have a mixture between setOf and [] which is not nice.

@janvladimirmostert That could be addressed by type-coercion, as I mentioned above, and is done in Swift.

@darkmoon_uk

[1, 2, 3] as Set<Int>

or

[1, 2, 3].toSet()

is comparable to

setOf(1, 2, 3)

Yes, that’s what I mean, #1 or alternate form:

val mySet : Set<Int> = [1, 2, 3]

Either way the type is coerced.