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

[David Alayachew]

I am in the camp of "do it all, or don't do it at all."

Either this "quiescent" functionality elevates past for-loops and becomes
available to ALL local variables, or this just shouldn't be done at all.
For-loops (even loops in general) happen to be the most obvious pain point,
but they certainly aren't the only one.

That said, even if we apply this quiescent functionality to all local
variables, we would only be scratching the surface of the REAL problem --
CORRECTLY outlining when and where it is TRULY SAFE to use a variable's
value.

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.
The rules for safety do not align with what is TRULY SAFE. So much so, that
even beginner's to this language can see the excessiveness of the rules
here.

Here is an example of what I mean when I say we are only scratching the
surface.

https://stackoverflow.com/questions/75072937/why-does-my-lambda-get-illegal-forward-reference-but-my-anonymous-class-does-no

This also bumps shoulders with your "before super()" work Archie.

We intuitively "know" that something like this should be possible, but the
language doesn't expose any way of doing this without some level of
indirection, duplication, or assignment after the fact. Just like a dummy
variable for for-loops.

On Tue, Dec 10, 2024 at 1:31 PM Tagir Valeev <amaembo at gmail.com> wrote:

> Hello!
>
>
>
> On Tue, Dec 10, 2024, 18:57 Archie Cobbs <archie.cobbs at gmail.com> wrote:
>
>> On Fri, Oct 25, 2024 at 10:02 AM Archie Cobbs <archie.cobbs at gmail.com>
>> wrote:
>>
>>> Is there some quasi-consensus to go forward with this idea for fixing
>>> basic for() loops?
>>>
>>
>> (Hmm, nobody responded yes and nobody responded no...)
>>
>
> Just for the record: I previously said that I don't think we should
> salvage classic for loop, because it's awful. Instead, we should invest
> into adding first-class ranges to Java, or at least library support, to be
> able to write something like
>
> for(int i: rangeClosed(1, 3)) {
> ...
> }
>
> This way, the lambda problem will be solved automatically, and people will
> get much more readable and much less errorprone way to iterate over
> integers.
>
> I still stick to this point of view.
>
> With best regards,
> Tagir Valeev
>
>
>> Now that JDK 24 is out of the way, I'd like to get some kind of final
>> adjudication on whether to continue pursuing this idea from this list.
>>
>> If everyone is good with doing this then I'm happy to continue working on
>> it, otherwise I'm happy to shelve it. I would just like to tie up the loose
>> end one way or another.
>>
>> To recap: the idea is to allow loop variables declared in basic (old
>> style) for() loops to be captured in the body of the loop as long as they
>> are not reassigned in the body of the loop (but they may be reassigned in
>> the loop step). For example:
>>
>> for (int i = 1; i <= 3; i++) {
>>     Runnable r = () -> System.out.println(i);   // allow this
>> }
>>
>> There was lots of good discussion and we did narrow down the idea to
>> what's described above. However I'm unclear on whether to now proceed with
>> asking for additional reviews, etc. and don't want to presume.
>>
>> If nobody replies I won't ask again :)
>>
>> FWIW here's what has been drafted so far (all subject to improvement of
>> course):
>>
>> Bug: https://bugs.openjdk.org/browse/JDK-8341782
>> CSR: https://bugs.openjdk.org/browse/JDK-8341783
>> JEP: https://bugs.openjdk.org/browse/JDK-8341785
>> JLS: https://bugs.openjdk.org/browse/JDK-8341786
>> PR: https://github.com/openjdk/jdk/pull/21415
>>
>> Thanks,
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241210/1f242b31/attachment-0001.htm>