<div dir="auto">I'm sorry but I think I'm just very bad at explaining. </div><div dir="auto"><br></div><div dir="auto">What I'm just trying to say is that the only thing that I think would be beneficial in terms of the api changes is that instead of passing the lambda that is doing all the safe keeping for the user (because it limits what can be done because of the usage of lambda) one would be able to literally do the same but not through the lambda but through manual start and stop. The rest of the assumptions would remain the same regardless of whether one using a lambda or not. </div><div dir="auto"><br></div><div dir="auto">I look at my request in a way as if you could do try with resources or manually call close in the finally block. In our scenario either the user passws the lambda or manually create the scope, runs the code (lambda) and closes the scope. Scope opening and closing would do exactly the same what it's being done under the hood when you call the lambda version.</div><div dir="auto"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Pozdrawiam / Best regards,</div><div>Marcin Grzejszczak</div><div><br><div><a href="https://marcin.grzejszczak.pl" target="_blank">https://marcin.grzejszczak.pl</a></div><div><a href="https://toomuchcoding.com" target="_blank">https://toomuchcoding.com</a></div></div></div></div></div></div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jun 2024 at 19:34, Robert Engels <<a href="mailto:robaho@icloud.com">robaho@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But x == y does not require immutability, .e.g:<br>
<br>
final ScopedValue aScopedValue = …<br>
<br>
Recorder r = aScopedValue.get();<br>
<br>
r.recordSomeValue();<br>
<br>
final Recorder = aScopedValue.get();<br>
<br>
r.close() -> e.g. writes values to server…<br>
<br>
so the scoped value is not immutable, only the reference is constant.<br>
<br>
This doesn’t match the JEP or I am misunderstanding it.<br>
<br>
>  final ScopedValue aScopedValue = ...;<br>
>  final var x = aScopedValue.get();<br>
>  // Any Java code at all...<br>
>  final var y = aScopedValue.get();<br>
<br>
<br>
<br>
> On Jun 10, 2024, at 12:29 PM, Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com" target="_blank">aph-open@littlepinkcloud.com</a>> wrote:<br>
> <br>
> On 6/10/24 17:25, Robert Engels wrote:<br>
>> I think the question is more - what are the threads doing with this<br>
>> object between the open and close. This is what controls whether or not<br>
>> the object can be immutable - which from my reading is the general<br>
>> design/limitation of a scoped variable.<br>
> <br>
> Exactly. So something (what?) returns a Scope object. But that can't change<br>
> the current scoped value context.<br>
> <br>
> Here's a fundamental property of a scoped value:<br>
> <br>
>  The result of aScopedValue.get() does not ever change within the execution<br>
>  context of a method. Sure, its value might get overridden in the context of a<br>
>  callee, but when that callee returns the scoped value has its original<br>
>  value.<br>
> <br>
>  So, in this code<br>
> <br>
>  final ScopedValue aScopedValue = ...;<br>
>  final var x = aScopedValue.get();<br>
>  // Any Java code at all...<br>
>  final var y = aScopedValue.get();<br>
> <br>
>  assert(x == y); // Always succeeds<br>
> <br>
> That is to say, you can read a scoped value, put it in a local, and use<br>
> that local, and it is a hard guarantee that will have exactly the same<br>
> effect as repeatedly calling aScopedValue.get() .<br>
> <br>
> -- <br>
> Andrew Haley  (he/him)<br>
> Java Platform Lead Engineer<br>
> Red Hat UK Ltd. <<a href="https://www.redhat.com" rel="noreferrer" target="_blank">https://www.redhat.com</a>><br>
> <a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank">https://keybase.io/andrewhaley</a><br>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
> <br>
<br>
</blockquote></div></div>