<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Thu, Jun 1, 2023 at 12:38 PM Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com">attila.kelemen85@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><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">David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> ezt írta (időpont: 2023. jún. 1., Cs, 19:02):<br></div><div class="gmail_quote"><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:arial,helvetica,sans-serif">What would happen if there was some context which is implemented in some way *other* than ScopedValue? For example, using thread locals, or a field on Thread, or something like that?</div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><br></div></div></blockquote><div><br></div><div>I understand your implication that I'm being a little bit hypocritical by concerning myself with SV, but not with others. And of course that is unfortunate, and I can't do anything about it. But the reason I care more about the SV scope than others is because I see scope to be more important, because this looks to me as a promising emerging concept. That is, we could have a future, where SVs are promoted properly everywhere (for example, StructuredTaskScope propagates it to the child tasks), What I mean by "promoted properly" is that at some point (there are various missing tools for that still) we could have what I would call a "properly scoped" application, where opening a new scope in `main`, whatever I set there will be visible to all application code, and if started so (there could be an implicit virtual scope for `main` as well), then the whole application would sit in a scope tree (even with concurrency considered) which would allow me to reason correctness about my code better. In such a world, a DI framework like I mentioned could be useful (and I believe a lot of other future APIs could benefit from proper scoping).</div></div></div>
</blockquote></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What I for one do *not* want is for someone other than myself to decide what "properly scoped" means for a given piece of code that I write, nor do I want behavior outside what is strictly required for implementing locally scoped variables.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Let me give a real-world example of why this is a problem. We have a security identity framework where our identities are associated in the manner of ScopedValue. A user may query what identity is currently active, and the user may execute some block of code with a new active identity. However, we found early on that some existing frameworks - like the Servlet specification for example - do not allow us to interpose a call like identity.runAs(() -> { ... }) in the midst of handling a request, for right or for wrong. So instead what we offer is a way to lexically scope a "flexible identity association". The identity may be changed within the scope of an operation, but the flexible association does not escape the bounds of the lexical scope that it was run under.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Why is this a problem? If you have some means to capture - even just for the purposes of verification - the "scope" as defined by all active ScopedValues, your expectation may be that you have captured the active identity that was present at the time of the capture. However this would not be the case in practice, and so you'd have a wrong "answer". In other words, the semantic meaning of what I store in an in-scope scoped value association has a bearing on what it means to capture it, and that semantic meaning is nobody's business but my own. Therefore, any API which broadly captures all scoped values for *any* reason is also semantically meaningless and therefore misleading at best, and disastrous at worst (think CVEs).</div><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If I control a scoped value, then I want nobody to have access to it for any reason at any time without my explicit mediation and permission. I think this is critical to the design, and I think that trying to impose a greater framework on what is essentially a mechanism for locally-scoped variables would be a mistake, and I further believe that this mistake could result in vulnerability to exploitation. Given that any locally-scoped variable mechanism may be used to implement any other locally-scoped variable mechanism, my opinion is that if you want locally-scoped variables which carry some additional meaning or behavioral constraints above those established by ScopedValue, you can implement one yourself (see Jakarta Context Propagation for example). ScopedValue, being the new foundational means to achieve local scoping, would not be the correct place to do this since any assumptions or behaviors implicit in its usage would inescapably creep into that of everything derived from it. Which I guess you view as a feature but I view as a potential disaster.</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>