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

[Maurizio Cimadamore]

On 23/10/2024 13:00, Ron Pressler wrote:
> That x really means something subtly different in the foreach loop and
> the classic loop is more of an implementation detail. I don’t know the
> history of that choice, and it did predate lambda, but if it was made to
>   allow a final index to be captured in an index class, then
> capturability is the motivation for that detail.

I don't disagree that is a matter of perspective (I called it 
subjective). As I stated:

> How you "fix" this largely depends on (a) how you find this asymmetry 
> annoying (which likely depends on exposure - and different code bases 
> might have different levels of that) and (b) how much your developer 
> intuition is trained to view the loop induction variable as a single 
> mutable *variable*, or a series of *values* where each value is 
> derived from the former in a controlled fashion. I don't have a strong 
> (enough) opinion on either :-)

IMHO both (a) and (b) are subjective calls. I feel that some developers 
will stand by the asymmetry because for-each is special, and doesn't use 
mutation (no need to do `i++`) so _of course_ you get a "fresh" `i` on a 
for-each iteration (but not in an imperative for loop). This is further 
reinforced by the fact that you can add `final` on for-each variables, 
but not in the imperative loop induction variables.

Other developers will find this distinction annoying, because in a 
well-behaved counted loop, the mutation of the induction variable is so 
controlled that it can largely be ignored (and be treated as an impl 
detail).

I think both views have their own merits

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241023/96fc813f/attachment-0001.htm>