<div dir="ltr"><div class="gmail_default" style="font-family:monospace">Thanks for posting Kevin.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">To my understanding, the other mailing list is when they want an exclusive chat, whereas amber-dev is a free-for-all.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">But in regards to your post, it sounds like your 2 points boil down to the following.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Would that be a correct summary of your post?<br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2024 at 6:00 PM Kevin Bourrillion <<a href="mailto:kevinb9n@gmail.com" target="_blank">kevinb9n@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><a href="https://mail.openjdk.org/pipermail/amber-spec-experts/2024-December/004229.html" target="_blank">https://mail.openjdk.org/pipermail/amber-spec-experts/2024-December/004229.html</a></div><div><br></div><div>That might have been cringe of me since this is already a 60-count thread as it is; if so... sorry!</div><div><br></div><div><div>(reminder: non-EG members can subscribe to amber-spec-<i>observers</i> to follow that traffic.)</div><div><br></div></div><div>I also gave my last-gasp consolidated argument <i>against</i> the change in reply, so we'll see.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2024 at 2:24 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2024 at 2:33 PM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks for the comments.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 10, 2024 at 8:44 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:monospace">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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>FYI I'll also ask my question on amber-spec-experts to get their opinion.<br></div><div><br></div><div>Thanks,<br></div><div>-Archie<br></div><br></div></div>
</div>
</blockquote></div>
</blockquote></div>
</blockquote></div>