On Wed, Apr 15, 2026, at 11:39 AM, Alex Rock wrote: > 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.
The RFC lists several. It's also all over Python code and has been for years. Though to be sure, people writing `using` blocks will outnumber those writing custom context managers 100:1, I imagine. That's fine. > 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. "Big" seems like a fairly subjective word to use here. It's just an interface and some desugaring. Compared to many of the changes already added just in this release, this is a small impact RFC. :-) And we know it's overhead: It's a couple of instructions that you would have written manually anyway, plus 2 method calls, which you may have had anyway. So, negligible in practice. > 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. Almost every language has closures with capture now. Only two require explicitly listing values to capture: PHP and C++. Everyone else figured out how to do it safely. The problem with JS is that it's by ref capture. But that's off topic, as we're discussing a feature that doesn't impact closures at all. If you want to make a separate proposal that leverages closures, you're welcome to do so, but that's not what this RFC is about. --Larry Garfield
