Kotlin 1.3


#1

Is there any public roadmap for Kotlin 1.3?

I’m particularly interested in collection literals.


#2

Since I had the same interested in the past (and today), I suggest to put a “roadmap” link on the homepage. The roadmap itself could link KEEP issues.


#3

Nothing in https://github.com/Kotlin/KEEP for collection literals. Does that mean they’re not expected any time soon?


#4

Collection literals are not such a great idea. For an explanation:


#5

That just means they couldn’t come up with a good solution. Ideally there would be a combination of compiler and library support, as was done for coroutines.

There have been a few suggestions of how to do this already, including some from JetBrains engineers. The general idea is that { ... }, with an inferred or declared type, will trigger the compiler to find a method with a specific name and signature which can create that type.


#6

Why do you need Collection Literals? There’s a standerd functions like mapOf(), listOf() & setOf() and much more to get things done.


#7

{1:a, 2:b, 3:c, 4:d, 5:e, 6:f, 7:g}
vs
mapOf(1 to a, 2 to b, 3 to c, 4 to d, 5 to e, 6 to f, 7 to g)

is much cleaner, particularly in DSLs. Groovy Gradle scripts containing maps are a good example, they become very ugly when translated into Kotlin script.


#8

From my point of view an “association” operator (like : in your example) would be sufficient. I consider the library approach to be more clean from a platform perspective.

mapOf(1:a, 2:b, 3:c, 4:d, 5:e, 6:f, 7:g)

#9

I think the biggest pain point are DSLs. Having collection literals would open up very nice possibilities in DSLs. Gradle scripts are a good benchmark.


#10

KEEP for Collection Literals: https://github.com/Kotlin/KEEP/issues/113


#11

What’s the current status of 1.3? I see a new branch 1.3-M1 on Kotlin’s repository. Looks like they are planning to introduce unsigned types. Is there any tentative roadmap?


#12

Funny. Working with collections in Java is traditionally a huge PITA.