Thanks everyone for feedback provided so far. Do not stop. While we’re analyzing it, I’ll post here some things we have already spotted during our review and plan to fix before release.
###Operations on maps and null values
We have several extensions for Map and MutableMap in the standard library, namely getOrElse, getOrPut, getOrImplicitDefault. They all try to get a value mapped to the specified key, or execute Or-branch in case if the key is missing from the Map.
This behavior differs from the one of similar functions like putIfAbsent or computeIfAbsent in java.util.concurrent.ConcurrentMap or java.util.Map from JDK8. These functions treat a key mapped to a null value the same way as a key missing in the map.
Provided these JDK8 operations would be eventually available for kotlin.Map it would not only lead to inconsistency in null handling, but also make us unable to use these function to implement our own extensions. One notable example is getOrPut for ConcurrentMap which we were unable neither to implement according to its contract in a concurrent-safe manner, nor to provide an overload of getOrPut for a subset of ConcurrentMaps with non-nullable values. That time we had to introduce an instantly deprecated overload for ConcurrentMaps and provide an extension with new name concurrentGetOrPut.
As a result we’re tending now to change the contract of our operations to treat nulls mapped to keys the same way as if those keys were missing. For example getOrElse would call defaultValue function when it encounter null value, and getOrPut would put new value over the null value.
Note that the behavior would change only for the maps that could contain nullable values.