[NNBD] Type promotion via flow analysis fails in nested loops

[nex3]

The following code:

int foo(int? arg) {
  arg = 0;
  while (true) {
    while (true) {
      arg++;
    }
  }
}

produces this error:

  error • The method '+' can't be unconditionally invoked because the receiver can be 'null'. • test.dart:5:7 • unchecked_use_of_nullable_value

Despite the fact that arg is always provably non-null by the point the ++ happens.

[stereotype441]

Yes, this is a known limitation of flow analysis. We deliberately decided to make the algorithm work in a single pass through the source code (with limited look-ahead to find writes inside loops) rather than iterate to a fixed point. So when flow analysis reaches the top of the first while loop, it sees that the loop contains a write to arg, but it doesn't yet know the type of the value written to arg. So it makes the conservative assumption that on any future iteration of the loop, arg might be null.

[nex3]

For better or for worse, NNBD makes flow analysis a really substantial part of the developer experience of the language. In order to write correct code, developers now need to have a mental model of how the analyzer will track nullability. Roughly speaking, the intuitive model is:

• Once a variable is unconditionally assigned to a non-nullable type (or assigned in both branches of an if block etc), all references afterwards treat it as non-nullable (until it's assigned to a nullable type again).

Whenever the actual behavior breaks from this model, it causes developer frustration and a need to do elaborate workarounds. It makes the substantial value provided by NNBD feel like a chore rather than a boon. This is particularly true because TypeScript—by far the most popular language with a similar nullability model, and thus a source of user expectations—does handle cases like this as expected. As such, I strongly encourage you to rethink the simplicity of the flow analysis model to allow it to better match developers' intuitive understanding of how it "should" work.