JDK-8300691 - final variables in for loop headers should accept updates
Kevin Bourrillion
kevinb9n at gmail.com
Mon Oct 21 17:21:31 UTC 2024
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/aa373e73/attachment-0001.htm>
More information about the amber-dev
mailing list