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

[Brian Goetz]

I've noticed people often use the word "common" when they mean something 
else.  This is usually relative to their own personal experience: "I 
commonly see..." But that doesn't necessarily make them "common"; if you 
did a query over all of Github, the percentage of loops that are of this 
"common" idiom would surely be ... vanishingly uncommon.

I think what you mean is "not unheard of".


On 10/21/2024 1:37 PM, Holo The Sage Wolf wrote:
>
> I disagree with the idea that "ranges" replace loops.
>
> It is a common to see stuff like:
>
> for(var x = buffer.read(); x != -1; x =buffer.read())
>
> Or
>
> while((x = buffer.read()) != -1)
>
> In both cases, x is most likely (effectively) frozen inside the 
> loop-clause, there is no reason to not treat it as (effectively) frozen.
>
>
> Yes it is technically possible to wrap those in Iterable, but I don't 
> see this pattern die any time soon
>
>
> On Mon, 21 Oct 2024, 20:22 Kevin Bourrillion, <kevinb9n at gmail.com> wrote:
>
>     well, uhh, "nay" :-)
>
>     But seriously, I don't disagree that in Example A it's more than
>     sufficiently unambiguous which value the developer wants. I just
>     feel like this whole topic is uncomfortably intricate and messy,
>     and the specific benefits of the change don't feel to me like they
>     will ever be worth even the time that's /already/ gone into
>     discussing it, especially when (as Tagir said) what users really
>     want is loops over ranges anyway.
>
>     To me changing nothing feels like winning here, but that's just me.
>
>
>     On Mon, Oct 21, 2024 at 10:00 AM Archie Cobbs
>     <archie.cobbs at gmail.com> wrote:
>
>         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/d6ef3c12/attachment-0001.htm>