What is the point of the immutable collections lib (<https://github.com/Kotlin/kotlinx.collections.i...

# announcements

[Stephan Schroeder]

What is the point of the immutable collections lib (https://github.com/Kotlin/kotlinx.collections.immutable) given the the Kotlin collections are already read only? Just to make sure that other devs can’t cast it back to MutableCollection??

[Artyom Degtyarev [JB]]

https://github.com/Kotlin/kotlinx.collections.immutable/blob/master/proposal.md ?

[serebit]

The immutable collections lib is truly immutable, while List in the standard library merely obscures the methods of modifying the data in the list.

[Dias]

Alternative:
Use mutable collections, but once they are populated expose them only though their read-only interfaces. This pattern is mostly used in the standard library collection operations.

Pro: mutable collection implementations are generally more memory efficient, require less allocations during and after their populating.
Con: collection can be cast back to mutable (e.g. involving platform types), and then unexpectedly mutated.
Con: different snapshots of a collection do not share any element storage.
Con: defensive copying of the resulting collection is still required later in a chain of operations.
Con: mutable collections need safe publication to share them to a different thread.

[Marko Mitic]

They are not persistent (useful for immutability and functional programming)

[Stephan Schroeder]

so it basically improves the convention of not modifying read-only lists to a certainty. (and it saves a bit of data when copying a readonly-collection with the intention of modifying it). I can see value in that 👍 (even more if would share maps between threads)