Confusion about the behavior of Dart closures capturing variables in loops

[YuyeQingshan]

Recently, I came across some code in tests/language/loop/for_variable_capture_test.dart that has piqued my interest regarding how Dart handles variable capture in closures within loops. I'm looking to gain a deeper understanding of this behavior, as it seems to have some nuances that I'm not fully grasping.

Here's the code snippet:

initializer() {
  var closure;
  for (var i = 0, fn = () => i; i < 3; i++) {
    i += 1;
    closure = fn;
  }
  Expect.equals(1, closure());
}

The Expect statement in the code passes, indicating that the value returned by the closure() is 1.

I also rewrite the equivalent code in Swift and JavaScript, and in those languages, calling the closure returns a value of 4, which aligns more with my expectations. While Dart does not seem to handle this in the same way, and I'm curious about the rules governing this behavior.

Could someone please explain the rules, and Thank you in advance for any insights you can offer!

Dart info

• Dart 3.1.5 (stable) (Tue Oct 24 04:57:17 2023 +0000) on "macos_arm64"
• on macos / Version 14.5 (Build 23F79)
• locale is zh-Hans-CN

[dart-github-bot]

Summary: The user is confused about why a Dart closure captures the loop variable's final value (1) instead of the value it had when the closure was created (3). They compare this behavior to Swift and JavaScript, where the closure captures the value at the time of creation.

[eernstg]

A C-style for statement (like the one you mention) will have a fresh variable for every iteration of the loop. This means that when you first initialize fn with the value () => i, it will return the i which is associated with the first iteration of the loop (if any). This remains true no matter how many times the loop is executed, because there are no further assignments to fn.

So closure = fn will just keep setting closure to the function that prints 1.

You could change the example such that it refers to the current variable named i during each iteration:

initializer() {
  late int Function() closure;
  for (var i = 0; i < 3; i++) {
    i += 1;
    closure = () => i;
  }
  print(closure()); // Prints '3'.
}

The general rule is that whenever a loop variable like i is captured, you'll get the variable which is associated with the current iteration.

Note that this allows things like for (final i in [1, 2, 3]) print(i);, which is arguably a bit more declarative than the same thing with var i.

[lrhn]

The Dart for loop was deliberately designed to avoid common pitfalls from other languages, which is why it differs from those other languages.
As @eernstg says, each iteration has its own instance of the variables. At the start, the var i = 0, fn = ... is run to create the first set of variables and their initial value, before executing the body.
On the second and later iterations, a new variable is created with the same name and the current value of each variable from the previous loop, then the increment expressions are executed, and then the loop body runs again with those variables.

That ensures that any closure you create inside the body will refer to the values of the current loop iteration.

It gets weird when you create closures inside the initializer or increment expressions, because those are not run on every iteration.

The loop behaves (something like) if it was written as:

void main() {
  var closure;

  var _loopFirst = true;
  late int _prev_i;
  late int Function() _prev_fn;
  while (true) {
    int i;  // Inferred types.
    int Function() fn;
    if (_loopFirst) {
      // Initializer
      i = 0;
      fn = () => i;
      _loopFirst = false;
    } else {
      i = _prev_i;
      fn = _prev_fn;
      // Increments
      i++;
    }
    // Test.
    if (!(i < 3)) break;
    _body:
    {
      // Body - with any `continue` -> `break _body;`.
      i += 1;
      closure = fn;
    }
    _prev_i = i; // Capture values just when exiting body.
    _prev_fn = fn;
  }

  print(closure()); // 1
}

(There are subtle differences, for example that the fn variable already exists in scope in the i initializer expression. The actual semantics are not defined by a rewrite, just by there being new variables introduced by each iteration, later iterations copying the values from earlier iterations.)

[YuyeQingshan]

Thank you @eernstg and @lrhn !!! now I'm clear about the logic and rules. This really helped a lot.