gbracha
commented
10 years ago Yes, this needs looking at. I'd argue that both const and final versions are implicitly disallowed, but we can revisit.
Set owner to @gbracha. Added Accepted label.
Open lrhn opened 10 years ago
gbracha
commented
10 years ago Yes, this needs looking at. I'd argue that both const and final versions are implicitly disallowed, but we can revisit.
Set owner to @gbracha. Added Accepted label.
eernstg
commented
6 years ago No milestone now: This will not block Dart 2.
The variant using final is supported today. We may still need to double check that const is prohibited, possibly based on existing rules about other topics than loops, hence the issue stays open.
srawlins
commented
5 years ago This was touched on recently; for example the analyzer now produces an error for for (const x =...
The specification of a for loop only handles the case for (var v = ...;...;...) ... but the syntax allows final, const and typed variables as well, as well as a non-declaration (plain expression or nothing) in the first part.
The implementations handle the non-declaration in similar ways: there is no loop variable, and the expressions just have to work on existing variables. That means that the algorithm in the spec cannot be used (it refers to a variable that doesn't exist).
Neither implementation handles 'final' gracefully: for(final i = 0; i < 10; i++) { print(i); } will throw a "no setter for i" in the increment operation. If following the "for(var..." specification, that may or may not be correct, since the fresh variable from step 4 isn't specified to have any type or finality. It should have the same type as the original variable (or you won't get type errors if assigning wrong values after the first iteration).
It would be preferable if the specification allowed 'final' in such a way that the variable is final except in the increment part of the for. I believe it was once defined that way.
A const declaration should probably just be disallowed. Neither implementation allows it.