Hacker News Reader

Comment by Scarbutt | Hacker News Reader

I don't know kotlin but if you read your collections link well, it does look like immutability was an afterthought, for starters, you can't create immutable persistent versions.

View on HN

It's not an afterthought, it's just that Kotlin is meant to interoperate with Java. Which is mutable.

However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf.

That looks very much like design and not like an afterthought.

There are no built-in immutable collection types; what Kotlin calls "immutable" is closer to C "const" i.e. it could be a view onto a list that's mutated elsewhere. This means you can't safely write a method that requires an immutable list; if you want to e.g. check the size of the list and then iterate over it, while maintaining the invariant that the number you got is the same as the number of iterations you're going to do, then you have to make a defensive copy, because there's no argument type you can ask for that means "actually immutable".

`List<T>` is technically immutable. You can make it mutable by casting to `MutableList<T>`, but that's something you have to explicitly do.

It's not immutable, it's something analogous to C const: you can't mutate it, but it can be mutated under you. If you call .size() on it twice you might get different results.

Reply on news.ycombinator.com