Dart cannot be sure that the method argument is not null if the argument is used in a closure

[ghost]

@vadlit commented on Apr 8, 2021, 10:40 AM UTC:

By some reason Dart cannot be sure that the method argument is not null if the argument is used in a closure. Property 'isEven' cannot be accessed on 'int?' because it is potentially null

void main() {
  foo(1);
}

void foo(int? nullable) {
  Future.delayed(Duration(seconds:0)).then((_)
  {
    if (nullable == null) { 
      nullable = 5;
    }
    if (nullable == null) {
      return;
    }
    print(nullable.isEven);
  });
}

In this case, as far as I undestand, there's no chance that the 'nullable' argument suddenly becomes nullable after the 1st check, because it's just a method argument, not class field.
The problem is not reproduced if remove the first check.

Dart 2.12.2
Windows

This issue was moved by keertip from dart-lang/sdk#45629.

[ghost]

@eernstg commented on Apr 8, 2021, 11:59 AM UTC:

Cf. dart-lang/language#1247. It's possible that the flow analysis could give special treatment to the case where all references (read & write) to a given local variable occurs in the same function literal or local function, even though the variable is declared in an enclosing function.

[lrhn]

The general issue here is that the exists a function which assigns to the variable, and we assume it can be invoked at any time. Even inside that function, we can't be sure that the same function won't be invoked again.
This code is so exceedingly simple that we can actually be sure nothing happens between the checks (== null calls no other code) and assignments (assigning to a local variable calls no other code). Most code isn't that simple, so it's not something we optimize for.

However, there is something we can do better here. We have a situation where all assignments to the variable assign a non-nullable value. We know that there is no assignment floating around which can make the variable null after we have checked that it's non-null.
After the

  if (nullable == null) {
    nullable = 5;
  }

we do know that nullable is non-null because it was, and there is no assignment to nullable anywhere which can invalidate that. Even if we don't know when this function is called, what state we start in or which code can run before, after or during the invocation, we still know that after proving that nullable is non-null by either failing at nullable == null or assigning 5 to nullable, it will stay non-nullable.

(I've done a proper move of the issue, to issue 1597, and will lock this move-bot version).