<div dir="ltr"><div dir="ltr">Em seg., 10 de jun. de 2024 às 17:47, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com">marcin.grzejszczak@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </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="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></blockquote><div> </div><div>This benefit of having ScopedValues "plug and play" into some interceptor architecture would come at the cost of removing the structural guarantee that ScopedValues scopes are entered and left correctly.</div><div>That guarantee would be degraded to a user requirement, which the platform would *not* be allowed to assume at the risk of undefined behaviour -- what happens if a super scope is closed before a sub scope?</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>