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

[Archie Cobbs]

On Mon, Oct 21, 2024 at 11:36 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> What I'm trying to say is that if a developer is confused (by the i++) on
> what "frozen" means for a loop variable, they won't find any clarity in our
> explanation that "lexically scoping trumps everything else". E.g. whether a
> developer reads the STEP part of a loop as part of the body (after the end
> of the body) or not is, I believe, a very subjective thing - and one which
> affects how any change we make in the area will be perceived (IMHO).
>
Yes, if a developer is mentally cutting and pasting the STEP onto the tail
of the BODY then you're right, that makes it appear as if the variable is
not really "frozen".

But the original basic for() proposal has the analogous problem - i.e., if
a developer is mentally cutting and pasting the STEP onto the tail of the
BODY, then in the original proposal the variable no longer appears to be
"effectively final in the body of the loop".

So it seems to me that this proposal and the original basic for() proposal
suffer equally in that particular respect, and such a developer is not
going to be satisfied by either of these new mental models.

> Of course, as with every new proposed feature, we hear a lot from
> developers who think that the new proposal addresses a specific pain point
> that they thought should never existed in the first place. But we tend to
> hear less about a less vocal portion of users who might just be silently ok
> with the status quo. Or maybe, in this instance, we don't hear from them
> because they aren't there (although, Tagir expressed some concerns [1], so
> I have to assume there are such developers out there  _somewhere_ :-) )
>
I too would like to hear more opinions... speak up, naysayers :)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241021/e6ce0f2f/attachment-0001.htm>