JDK-8300691 - final variables in for loop headers should accept updates

[Maurizio Cimadamore]

Interesting observation.

On 19/10/2024 18:14, Archie Cobbs wrote:

> But wait... what exactly is the meaning of the word "after" in that 
> observation? Does "after" mean "later in time as the program executes" 
> or simply "lexically later in the source code of the program"?

I agree with your subjective feeling that the latter seems to be more 
important when reading the code.

But, as you observed, for loops are still kind of problematic here, 
because the space vs. time conflict: e.g. even though a loop variable 
might not be modified after it is captured in a loop body, you can still 
see “previous values” of the captured variable, exposed via previous 
capturing lambdas.

I also wonder if saying that all that matters is the “space” dimension 
(e.g. where variable references occur lexically, in a program) would 
create asymmetries with some of the other flow-dependent analyses we do. 
For instance, DA/DU does not treat the loop body in a truly lexical 
fashion - e.g. something like this is an error:

|final int x; while (loopCond) { x = 1; } |

This might look good if the “time” dimension didn’t exist. But DA/DU 
takes time into account, and detects that |x| might be actually assigned 
twice.

In other words, to me the crux of the problem remains the definition of 
the loop induction variable. We want to carve out some special rules 
that allow us to treat the loop induction variable /as if/ it was a 
variable freshly declared inside the loop body (e.g. meaning that the 
assignment we see in the STEP part of the loop doesn’t really affect 
whether that variable can be captured or not).

That seems kind of an orthogonal extension to the one you are proposing 
here - surely, “effectively frozen” will allow capture for far more 
locals (as your finder experiments show), but we still need to somehow 
be able to special case the treatment for loop induction variables.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241021/6bc9534d/attachment.htm>