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

[Kevin Bourrillion]

On Tue, Oct 22, 2024 at 11:37 AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

>
> This made me realize this issue really is all just about naming. For
> example, outer instances are captured just like variables, but we don't
> have a problem there because the captured version of the variable has a
> different name inside the nested class vs. outside (i.e., "Outer.this" vs.
> "outer", if you create the nested class via "outer.new Inner()").
>
> So with a captured variable, we are using the same name for what are in
> reality two different things. But instead of saying "these are really two
> different things" we say "there is only one possible value this/these
> things could have no matter where you are and so you can just pretend there
> is only one thing".
>

sounds right to me.


Entering personal opinion territory here... I wouldn't see such a big
> downside with allowing capture of any variable. Maybe that's just because I
> know how it really works? It's just a read-only snapshot taken at that
> point. Even if it were a new concept, that's just not a hard concept to
> grasp... especially in light of the many trickier Java topics like
> superclass constructors invoking subclass methods, mutual recursion between
> class initializers, anything to do with multi-threaded code...
>

I suspect it is specifically the fact that you can reference a field
without `this.` and it really captures `this` that creates the problem
here. Users would be regularly surprised that fields and locals don't work
the same as each other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241022/8f8dbf79/attachment.htm>