Using a late final variable as loop variable for for/in gives incorrect late errors

[lrhn]

Example:

void main() {
  late final int c;
  var ints = <int>[1];
  for (c in ints) {
    print(c);
  }
}

This code should be able to run without invalidating any late variable constraints.

The analyzer reports:

The late final local variable is already assigned.

The front end (DDC, Dartpad, main branch) reports:

main.dart:4:8: Error: Can't assign to the final variable 'c'.
  for (c in ints) {
       ^

The analysis should not consider c definitely assigned in the loop header (since it isn't definitely assigned, the example code above would only assign to it once).

The error message suggests that the logic for for/in (which is not well specified to begin with) has some clause saying that the variable must not be final. That would predate late variables, and shouldn't be take verbatim any more.
The variable must be assignable, which means it must:

• not be const,
• must not be final unless:
  • it's definitely unassgned, or
  • it's late and potentially unassigned.

Assignment analysis of a for/in (and while) loop should treat the loop variable as:

• Definitely assigned if it's definitely assigned before the loop.
• Potentially assigned before the loop assignment if it's not definitely assigned before the loop.
• Definitely assigned after the loop assignment and after the loop.

Basically, it should work just as if the loop was written as:

void main() {
  late final int c;
  var ints = <int>[1];
  for (final int _$tmp in ints) { // Introduce same context type that `c` would.
    c = _$tmp;
    print(c);
  }
}

which both CFE and analyzer accepts.

(I don't think a late final loop variable is something anyone would ever write, so not a high priority to fix.)

@stereotype441

[eernstg]

The specification isn't entirely complete on this topic, but I do think we can find most of the rules that are needed to clarify this situation.

The for-in loop for (c in ints) ... is actually specified to perform an assignment to c during the execution of the body of the loop (quote from here):

If S is a for statement or a for element in a collection, whose forLoopParts take the form of a for-in loop, [then assignedIn(S) uses] the body of S [as its scope].
...
a loop of the form for (x in ...) ... (where x is declared elsewhere in the function) is considered to assign to x.

The rule about the flow analysis of a for-in statement is found later in the same document, but it doesn't spell out exactly how the assignment mentioned above is taken into account. There's a TODO about it:

this glosses over how we handle the implicit assignment to X.

This means that we can't see precisely how the for-in statement updates the variable model of c to represent the synthetic assignment to c in the body, but it seems reasonable to say that c is 'definitely assigned' in the body, after the synthetic assignment to c (if the flow analysis takes this assignment into account). It is also 'not definitely unassigned' in the body, and it is 'not definitely unassigned' in code which is executed after the body, and before the first iteration, and after the loop as a whole.

In particular, it would then be 'not definitely unassigned' before the synthetic assignment, which would imply that the synthetic assignment to c should not be reported as an error.

[stereotype441]

@lrhn

Assignment analysis of a for/in (and while) loop should treat the loop variable as:

• Definitely assigned if it's definitely assigned before the loop.
• Potentially assigned before the loop assignment if it's not definitely assigned before the loop.
• Definitely assigned after the loop assignment and after the loop.

It's not sound to consider the loop variable as definitely assigned after the loop, because the loop might execute zero times. I think the last bullet should be replaced with something like:

• Definitely assigned in the body of the loop (i.e. after the implicit assignment).
• Potentially assigned after the loop.

(I don't think a late final loop variable is something anyone would ever write, so not a high priority to fix.)

Agreed. Accordingly, I'm classifying this as P3.