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

[David Alayachew]

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/0bb1c641/attachment.htm>