<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">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 gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Dec 11, 2024 at 2:24 PM David Alayachew <<a href="mailto:davidalayachew@gmail.com">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>