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

[David Alayachew]

Thanks for posting Kevin.

To my understanding, the other mailing list is when they want an exclusive
chat, whereas amber-dev is a free-for-all.

But in regards to your post, it sounds like your 2 points boil down to the
following.

Allowing values from mutating variables to be captured in a lambda will
open the serious can of worms about where and when a mutable variable's
value is safe to capture. We currently have a very simple (albeit,
restricting) set of rules that leave out much of the ambiguity by just
universally saying "NO" unless it is effectively final.

Would that be a correct summary of your post?

If so, then I firmly agree with you. I'd even go further -- if we do decide
to open up the can of worms, we can't just kill one of them -- we need to
kill them all. We need to fully specify when and where it is safe for a
mutable variables value to be used. No special-casing for for-loops -- the
logic would need to be something that can be UTILIZED by for-loops, but
shouldn't belong to them at all.

And while I would prefer to kill all the worms (again, even beginner's
lament that they KNOW they are safe to use the value), I am also ok with
just doing nothing and sticking with the status quo.

On Wed, Dec 11, 2024 at 6:00 PM Kevin Bourrillion <kevinb9n at gmail.com>
wrote:

> 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/f40e1d97/attachment-0001.htm>