List/ImmutableList & Map/ImmutableMap might be less problematic than MutableList/List & MutableMap/Map

1

I'm currently wading through code trying to get it to compile in Kotlin again with the recent changes to List/MutableList & Map/MutableMap. Code that used to work with java.util.List is now mostly borked; the fix seems to be remove imports to java.util.(List|Iterator|Map|Collection) then replace all uses of List with MutableList if its mutated, all uses of Map with MutableMap if its mutated (both of which are very common).

It strikes me that lots of code folks write will use List & Map and assume they are mutable (as thats always been the case with Java). Whereas Kotlin is redefining now what List and Map mean (removing lots of methods which will cause confusion).

I wonder if its going to ease the transition of code and programmers from Java to Kotlin if List and Map remain mutable (so they behave as Java folks expect, having the same APIs etc) and we instead introduce ImmutableList & ImmutableMap for those cases when a list or map are immutable?

Right now List / Map / Collection in Kotlin are confusing - as they’ve silently had lots of the API methods removed causing all kinds of surprising compile errors.

I propose we rename in Kotlin List -> ImmutableList and MutableList -> List so that in Kotlin and Java “List” is the same interface; and ImmutableList is a new sub-set of List etc.

2

I've gone through the same process and I disagree. It's a good idea that immutable is the default. Besides, this only affects existing Kotlin code.

3

Disagree. Most of the time data should be immutable. Mutable things should be designated explicitly.

4

Any code converted from Java will be affected. (e.g. if you use IDEA's convert to Kotlin code it will be broken)

5

This means that the converter must be fixed, not that we should rename things.