Re: [RFC] Context Managers

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