Well, in my eyes, this stuff is actually making code less safe and maintainable… You can either
- “play by the book” and write more code (e.g. these extra classes, copying stuff to locals and back, using lots of
?.let, etc). More code is harder to maintain almost by definition. - “know better than the compiler” and liberally use
!!… but doing this a lot will make it a habit, and once it’s a habit, there will be instances where the error is actually legit, yet will be ignored.
And here, I just thought of another case to demonstrate the sillyness of it all:
class Test {
private val lock = ReentrantLock()
private var foo: Whatever? = null
fun test() = synchronized(lock) {
foo = makeWhatever()
if (foo.something) {
// ERROR: Smart cast to 'Whatever' is impossible, because yadda yadda
}
}
}
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…
And please, there’s no need for a lecture on benefits of immutable objects - a large majority of my classes are immutable (that’s why I’d really like that const get() modifier 
), but in the end, some state has to change somewhere, otherwise the program didn’t actually do anything…