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

[Maurizio Cimadamore]

>> …
>> Of course you can argue it both ways: by making the new capture treatment only available for induction variables in for loops (where the variable is not mutated in the body) we do reduce (not eliminate!) the chances of somebody observing different values for the same induction variable.
> I don’t see the sub-point about “not eliminate”; I think the reduction is complete to the point of elimination, because of the special (weird) properties of the old-for loop.
Well, there's no sub-point - I'm merely stating the (perhaos obvious?) 
fact that if you allow to capture induction variable you can set up a 
contrived example where you execute a lambda which captures the 
_previous_ version of the induction variable. That said, the same thing 
happens in for-each loops - so we're back to the subjective judgment of 
whether it's ok for counted loop to have same rules of for-each loops 
despite a more explicit mutation (even if controlled).
> I also think the feature will be enjoyed far more than “20 or 30” times, or whatever corpus analysis tells us.  Corpus analysis by definition measures the way people have used the language in the past, and that is often affected by their avoidance of sharp corners in the language.  I believe this little polish of a central syntax in Java will affect the way people shape their code in the future.  At least, it will for me, because I know I’ve done extra work to avoid the sharp corner in the past.

Here I don't think I agree. It's not like developers are avoiding loop 
because the capture rules are what they are. If you need a loop, you 
need a loop. Maybe they are avoiding capturing lambdas - but again, 
replaced with what? Anonymous inner classes will have similar issues. 
And if you need capture you need capture - you can't make that go away. 
Perhaps they are disguising the capture a little harder, by using an 
array, or an AtomicXYZ. But I'd say that, while the numbers we have seen 
might surely underestimate things a bit, I don't expect to see dramatic 
differences in the wild.

There's another reason I think this is the case - since Java 8 there are 
often better ways to write loops: using the Stream API. Of course not 
every loop can be rewritten using streams, but a lot can, and developers 
have already done so - perhaps lowering the number of legacy loops (of 
all kinds) requiring some kind of capture.

Maurizio

>
> — John
>
> P.S. Archie, I don’t think character positions should be appealed to; that’s not a natural tactic for the JLS.  (Despite some very low-level and odd rules about forward references between field initializers, which sort of depend on character positions.)  Appealing to character positions instead of block structure inhibits understanding of code at the AST level (which IDEs want to do).  If I were going in that direction I’d piggy-back on the reachability analysis the JLS already has, in order to track setting of finals.  I’d ask, “can the captured variable be reassigned in some code B reachable from the capture point A?” in a way analogous to asking “can this final, once assigned at point A, ever be reassigned at point B?”  Note the connection to finals, which is not accidental.  Finals are all about saying, “this variable is only a value, and does not provide access to a future evolution of states”.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241023/707da7ca/attachment.htm>