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

[Kevin Bourrillion]

Being under the impression that user-facing language-change decisions
should be discussed in amber-spec-experts, I asked Archie to put a thread
there as well.
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-December/004229.html

That might have been cringe of me since this is already a 60-count thread
as it is; if so... sorry!

(reminder: non-EG members can subscribe to amber-spec-*observers* to follow
that traffic.)

I also gave my last-gasp consolidated argument *against* the change in
reply, so we'll see.


On Wed, Dec 11, 2024 at 2:24 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Sure, but the same rules that allow the compiler to know that it is safe
> to use the variable for that instance of the for loop is more or less my
> point -- that should be extended outside of for loops too.
>
> I just take issue with adding this only for for loops or just loops. I
> understand that it would be heavy to apply this for more than just
> for-loops, but not doing so runs the risk of foreclosing potential
> solutions in the future when someone else like you comes asking for this
> for contexts outside of loops.
>
> On Wed, Dec 11, 2024 at 2:33 PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> Thanks for the comments.
>>
>> On Tue, Dec 10, 2024 at 8:44 PM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> The entire reason that this feature is being considered is because WE
>>> KNOW that we are being safe, but the compiler doesn't have enough info to
>>> know.
>>>
>>
>> I think it's more subtle than that... the compiler often does have enough
>> information, but there are some other reasons trying to extend this to all
>> "quiescent" variables would be tricky.
>>
>> One issue is that the JLS doesn't talk about variables being captured &
>> duplicated - even though we know that's what actually happens in practice.
>> In the JLS there's only one variable. Therefore, any JLS change that
>> forcibly "reveals the truth" would be pretty disruptive (an example is the
>> simple rule "allow capture anywhere"). See previous discussions in this
>> thread for details.
>>
>> FYI I'll also ask my question on amber-spec-experts to get their opinion.
>>
>> Thanks,
>> -Archie
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241211/91d07b6b/attachment.htm>