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

[Holo The Sage Wolf]

The reason I said it is "common" is because it is something you see a lot
when you search "java read from buffer" in Google (3 out of the first 5
result, including stack overflow and Baeldung post.

Similarly to "java read from inputstream" (excluding the javadoc result,
which doesn't have an example on how to use inputstreams)

(SO and Baeldung seems to really like this pattern)

So I really meant "common" when I said "common", my sample was just
different from yours.

But even if we disagree on the usage of "common", I still my point is still
standing

On Mon, 21 Oct 2024, 20:53 Brian Goetz, <brian.goetz at oracle.com> wrote:

> 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/3a79644c/attachment.htm>