Le 15/04/2026 à 17:10, Larry Garfield a écrit :
I think you're missing the point of this construct. What you're describing is much closer to the recently-declined `let` scoping keyword (https://wiki.php.net/rfc/optin_block_scoping).
Yep, I would have been much more okay with a revised version of the `let` scoping keyword, though the implementation also seems quite complex too.
The entire point of context managers is to abstract away and make reusable the try-catch-finally logic. That logic needs to live somewhere so that it can be reused. That is what the ContextManager object is for. It's not a complication; it's the entire purpose of the RFC. Since you just recently joined the list you would have missed the earlier discussion in this thread of closures. (Seehttps://externals.io/message/129077).
I have read a few of the messages on externals.io, maybe not everything, but your answer indeed makes things a bit clearer. It mostly makes me think that this RFC is a bit complex and I don't see /many/ userland use-cases that would actually need this.
IMO, it tries to /make some safeguards/ implicit, like closing resources. I recognize that it's useful for this case, but does PHP really need a new feature this big "just" to close resources 10 milliseconds earlier in a process that takes 100ms anyway? The benefits would only go to projects with huge amount of concurrent calls, which are not all of them.
In short, closures are what people use today for this use case, but they're a PITA because they don't support auto-capture (unless you're using the single-line version). That makes them less common, because they're a pain to use in this case. In addition, they do create a new scope, which... is not what we want in this case. Not creating a new scope is a feature, not a bug.
No auto-capture in closures is IMO an actual *good* thing, because it avoids having issues with the current world of JS/TS where auto-capture is default, and it brings problems with references. My suggestion with the `scoped` keyword also carries auto-capture by design, which makes the "capturing system" (shadowing, references, etc.) less intuitive in the first place. It's "yet another thing to keep in mind" at first, but for legacy apps renovators like me, it's mostly "they haven't kept this in mind" debugging hell ^^', but considering there's always worse, it's negligible, especially if it's intended to be a new feature.
Still: creating a new scope makes things safer. It creates a new stack with its own pointers, and frees it at finish. They are a pain to use for now mostly because there's more code to write, it needs to be called (or auto-called with `()` after it), and capture must be explicit via `use` . The `scoped` keyword proposal automates all this with existing PHP features, while the ContextManager adds new features for that, and we don't know (yet) the overhead.
Sorry for being this picky :)
