A similar problem was discussed in this topic: Smart casts and nullability in single-threaded contexts.
Yes, that’s about it. At least I am not alone with that pain. My statement is that any real-world project will be full of !!, nested “let”'s or other ugly workarounds just to overcome this language design flaw.
The usability of Kotlin is like 3x better than Java’s in all other aspects, but for some reason, mutable nullable fields are comparatively horrible to use (and if it wasn’t for
lateinit, non-null fields would be just as bad)… It just seems like such a wart on an otherwise beautiful language…
Fully agree with @mslenc in that statement. It’s a pleasure to write in Kotlin after Java …unless you do it for real-world project which is full of mutable states, and you are responsible for access synchronisation. Compiler is your enemy there, this shouldn’t be so in a production-ready language. And as I said before, this situation is absolutely normal for imperative programming, problem is not in your code, it is in the compiler design. I hope that the language developers will understand this one day as well as the community (which I am pretty sure will happen while more and more people will try to use Kotlin for more complex projects), and then, I hope, there will be some solution.
Another point - actually this “problem” which the compiler is trying to fight with, is valid not only for nullable variables. Any mutable variable formally can be unexpectedly modified if the programmer is not taking care of it.
if (x == 42) {
thisFunctionWillCorruptDataIfArgIsNot42(x)
}
There is no principal difference if we expect non-null or any other expected values. Unexpected change of mutable state is exclusively programmer headache, the compiler just should not make it worse.