a = [0..100] and b = {"a":1, "b":2} are so simpl...
# announcements
i
a = [0..100] and b = {"a":1, "b":2} are so simple and plain to use
k
There are factory methods:
Copy code
val a = listOf(1,2,3,4)
val a1 = mutableList(1,2,3,4)
val a2 = (0..100).toList()

val b = mapOf("a" to 1, "b" to 2)
val b1 = mutableMapOf(....)
It might be that Kotlin doesn't use [] and {} because there are more than 1 implementation, (ArrayList, LinkedList) and they have mutable and immutable versions.
g
There are so many discussion about it and even KEEP proposal, please check it. It’s not even close so simple as you may think https://github.com/Kotlin/KEEP/pull/112
i
we can do a=[1,2] in C, Haskell, Python, and Javascript, the most languages support that, why not java/kotlin?
this KEEP seems good
I wonder if kotlin will support that list comprehension stuff one day?
no decorator, no generator, no comprehension, I think we're using some languages which stay on 90's
g
this KEEP seems good
No, it is not. It is full of problems
I wonder if kotlin will support that list comprehension stuff one day
It may of course, but we need good proposal for this. Existing one is definitely is not sufficient
no comprehension
Oh please, no
i
why those modern langauges features are so difficult to implent on java/kotlin?
g
What kind feature exactly?
i
the upside I said
g
there are many features
for example I’m strongly against comprehension
I think this syntax will not make anything good, it’s harder to read and write and already covered in kotlin perfectly using collection operators
4
If you want to know why collection literals are hard, just check disccussion
according to feature list that you mentioned, you probably have Python background, Kotlin is not Python, it has own history, own goals etc I mean everything is possible to implement, it’s just a matter of reason and complexity of it
i
I use several langauges
g
Kotlin is not Python
Or
Kotlin is not LanguageX
i
but those things are not every special stuff, like macro in lisp, pattern matching in haskell, continuation in scheme
or Promise in JS, Future in Python
I don't expect kotlint to implement those features, I know they may be difficult to kotlin
g
I’m not ready to discuss every particular feature and my opinion may not match Kotlin Team opinions, my point is simple: To implement any new feature in the language you need very good reason and a lot of pros that overweight cons. And if you have this reason and way to implement it, everyone may create KEEP proposal for Kotlin and discussed it with community and Kotlin Team
i
fine