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

[Holo The Sage Wolf]

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/1eec5193/attachment.htm>