I think it is coming: https://github.com/Kotlin/kotlinx.collections.immutable/blob/master/proposal.md

Why so confusing

Because Java and because backwards compatibility.

I heard people saying many times to not rely on the fact that you can mutate

List

at the moment because in future it might become fully immutable.

Well, the thing I linked is only a proposal and it seems it's not very fleshed out or even updated much. So... not sure. 🤷

So that means switch everything over to

immutableListOf()

instead of

listOf()

?

yeah that would suck

Because whenever I use

listOf()

I meant that I wanted an immutable list.

Exactly my thoughts.

I've thought about creating a

pListOf()

builder and pointing it to some Java persistent collections implementation

Maybe I am too influenced by Rich Hickey but to me, collections are very very important in any language. Without a good safe data manipulation, what's the point? All software does is manipulate data.

You could use the actual Clojure collections if you want, but I imagine they might be limited to Kotlin/JVM: https://github.com/aol/cyclops-react/wiki/Clojure-and-cyclops-collections

I don't care about multiplatform but I think collections is such a cornerstone of a language that they should come from the stdlib.. The principle of least surprise etc..

When you say that you can modify a Kotlin immutable list (returned by listOf for example) you mean only if you access the Java methods via the Java types, rather than the Kotlin methods, right?

Or you can cast it.

@greybird correct

That doesn't bother me so much, because I think I understand that a thin layer over the Java collections has benefits as well. It is certainly the simplest thing to provide, and as long as I stick to the Kotlin types I can get many of the benefits of immutability.

It's still annoying that you can't return the result from

listOf()

to java code and be sure that it's really immutable.

Yep.. also cue in heaps of people telling newbies how they can learn Kotlin without knowing Java. This is one of very real javaisms hidden below a thin layer of Kotlin just waiting to bite you in the a**

Well the latter is more a "problem" with the way the contracts are specified, but otherwise I agree.

To implement "real" immutable collections for functional style work is a big job, because they are designed to share memory between instances, when adding an element to create a new immutable collection for example. This is what scala's immutable collections do and what is talked about in the Kotlin proposal. I can understand why this is taking a while. But maybe, as a much simpler step, you would be pretty happy if the list returned by listOf, etc, is simply:

java.util.Collections.unmodifiableList(java.util.ArrayList())

so that Java code can't change it?

First of all, immutable collections have been implemented for JVM several times. You mentioned Scala but there is also Clojure that had it years ago. Also, I don't see a big risk in picking an implementation and then improving/changing it later as the state-of-the-art progresses. The interfaces would remain the same. As for your example, yes I was surprised this is not already the case and I don't understand what is preventing this intermediate solution.

Don't know. The only reason I can think of not to do it, is to avoid an extra object creation. But maybe the JB folks ran into other problems as well.