[-Yexplicit-nulls flow typing] Recognize when variable is monotonically not null

[strelec]

This proposal applies to:

1. private class fields
2. local variables that get referenced from closures.

Variable is monotonically not null if it starts as null, but once it is set to non-null, it can never become null again.

object A {
   private var s: String | Null = null

  def setA(newS: String): Unit =
     s = newS

  def doWork: Unit =
     if (s != null) println(s.toUpperCase) // does not compile now, but it should
}

[olhotak]

This was proposed in #14622, tried in #15123 #15124 #15127. Didn't get any traction.

[strelec]

This was proposed in #14622, tried in #15123 #15124 #15127. Didn't get any traction.

This is not what I am proposing. I am not proposing a new unitialized marker. I would not like that either.

I am proposing that the above example would just compile out of the box. At compile time you can see all the places an assignment happens, and if nowhere the null can be reintroduced, the program can compile.

Unless I am not understanding this correctly.

[strelec]

I have changed the proposal to private class fields only, so the scope where you have to track the variable is small.

But if that is too much, applying this proposal to local variables only is very welcome. Current flow typing implementation must already visit every reference to the var, so that should not add much additional compiler effort.

I assume flow typing currently also breaks for closures like foreach / map / for comprehensions, - therefore this would be a good QOL enchancement.

[olhotak]

The flow-sensitive analysis needs to happen during typing, when the compiler does not yet know the types of other expressions and therefore does not know whether assignments may write null into the variable.

The technical core of the earlier solution was to use type bounds to give the variable a type that is nullable when the variable is read but non-null when the variable is written. Such a type would then allow the flow-sensitive analysis to conclude that, once it has already observed a non-null value in the variable, that value will not then be overwritten with null in the future.

This was achieved in the earlier solution by a declaration type Uninitialized <: Null. In the scope of such a declaration, using String as an example, we have String <: String | Uninitialized <: String | Null. Thus, a variable of type String | Uninitialized then has exactly the desired property needed by the analysis: a value read from it is know to have type String | Null, but a value written to it is required to have type String. If the variable is ever observed to contain a non-null value, the analysis can conclude that it will continue to remain non-null and narrow the type read from it to String.