3 ms·

I think the reason for that is that Kotlin doesn't necessarily aim for immutability as much as it aims for read-only values. This is also why there is no truly

I think the reason for that is that Kotlin doesn't necessarily aim for immutability as much as it aims for read-only values. This is also why there is no truly immutable implementation of `List` in the stdlib, although the interface itself it read-only (but it can still point to a value that is being mutated somewhere else). I agree that true immutability - or code that is more obvious about avoiding side-effects - could be useful, but I don't think that was ever the goal.

usrusr 6y ago
That's certainly an accurate description of the cause. But I don't think that it's a valid excuse: not supporting immutability well is fine, pretending that you do when actually you don't is not. The kotlin defense to this surely is that immutability happily exists in val constructor args (with the usual exception: not transitive through references), but that's purely contextual and a difference that is very hard to represent at usage site (e.g. they look exactly the same in the intellij "javadoc" view). If for some reason bean-style methods had to be represented through var/val syntax, I think that it would have been much better if read-only calculated getters were represented by a var without set(), leaving val to cases where you're guaranteed to get the same when referenced twice (value set once in constructor or some lazyness shenanigans).