Stephan Schroeder

10/15/2019, 1:19 PM
What is the point of the immutable collections lib ( given the the Kotlin collections are already read only? Just to make sure that other devs can’t cast it back to MutableCollection??


10/15/2019, 1:21 PM
The immutable collections lib is truly immutable, while
in the standard library merely obscures the methods of modifying the data in the list.


10/15/2019, 1:22 PM
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

10/15/2019, 1:22 PM
They are not persistent (useful for immutability and functional programming)

Stephan Schroeder

10/15/2019, 2:43 PM
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)