Flow analysis is overly pessimistic about closures capturing for-in loop variables

[stereotype441]

The following code works in legacy mode:

List<void Function()> deferPrintingIsEven(List<num> nums) {
  List<void Function()> result = [];
  for (var n in nums) {
    if (n is int) {
      result.add(() {
        print(n.isEven);
      });
    }
  }
  return result;
}

main() {
  for (var f in deferPrintingIsEven([0, 0.5, 1])) {
    f();
  }
}

It prints:

true
false

It ought to work with the null safety experiment enabled as well, but instead it gives a compile error:

test.dart:6:17: Error: The getter 'isEven' isn't defined for the class 'num'.
Try correcting the name to the name of an existing getter, or defining a getter or field named 'isEven'.
        print(n.isEven);
                ^^^^^^

I believe what's happening is that flow analysis considers the variable n to be assigned to within the body of the method, so it cancels promotions on entry to the function expression. However, according to the spec, the for-in loop is treated as equivalent to:

  List<num> id1 = nums;
  var id2 = id1.iterator;
  while (id2.moveNext()) {
    var n = id2.current;
    {
      if (n is int) {
        result.add(() {
          print(n.isEven);
        });
      }
    }
  }

...which is accepted by flow analysis (because each initialization of n is in effect initializing a fresh variable, so there is no assignment that could clobber promotion).

Flow analysis should be changed so that the for-in form behaves the same as its desugared equivalent.

[leafpetersen]

Is this still planned?

[stereotype441]

I would still like to do this, especially because it means that code that used to work (prior to null safety) will stop working when null safety is enabled. However, time is drawing short and I might not get to it in time.

[stereotype441]

Whoops, fix has not landed yet.

[kevmoo]

@stereotype441 – I don't think you meant to have this closed by 27fc687 – right?

I think GitHubs auto-close logic caught you by mistake

[stereotype441]

@kevmoo thanks. This was fixed, but the SHA that fixed it should have been 53e707f.