English is currently available.
Kotlin DISCUSSION
My class has var label: String? = null. Inside a method I write if (label != null) { print(label.length) } and the compiler refuses: smart cast is impossible because label is a mutable property that could have been changed by this time. The same code compiles when label is a local variable.
I have just checked it for null on the previous line. What is the compiler worried about, and what is the idiomatic way to write this without sprinkling !! everywhere?
A smart cast is only allowed when the compiler can prove the value cannot change between the check and the use. For a var property it cannot: another thread could assign null after your check, or a function you call in between could do it. The compiler does not try to analyse that; it simply refuses for any mutable property.
A local variable is different because nothing outside the function can reach it. A local val, or a local var that is not modified between check and use and is not captured by a lambda that modifies it, is smart-cast without complaint.
The standard fix is to read the property once into a local val: val l = label, then if (l != null) print(l.length). You are now working with a snapshot that cannot change. The scope-function form does the same thing in one expression: label?.let { print(it.length) }, where it is the non-null snapshot.
When you only need a value out of it, the safe call and Elvis operators are shorter still: val n = label?.length ?: 0.
Avoid label!!.length as the fix. It compiles, but it reads the property a second time, and if the value did become null it throws NullPointerException; you have turned a compile-time guarantee back into a runtime one. Keep !! for cases where null really is a programming error and you want the crash.
If the property never needs to be reassigned, the simplest solution is to make it a val. A val property declared in the same module, without a custom getter and not open, can be smart-cast directly.
The same message appears in a few other situations, all for the same reason that stability cannot be proven: a val with a custom getter (each read may return something different), an open property (a subclass may override it with a getter), a property declared in another module (its implementation could change without recompiling yours), and delegated properties. The local-copy approach works for all of them.
It applies to type checks as well as null checks: if (shape is Circle) shape.radius fails on a mutable property and works on val s = shape.
Back to Kotlin community
