Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130647
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 15 Apr 2026 13:27:06 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <c28d0642-debb-4112-aab3-be0f364c5e4c@app.fastmail.com>
In-Reply-To: <cea1929d-44cb-4d60-aae9-2df894add108@gmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@app.fastmail.com>
 <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
 <7991abf6-9cc8-444e-885c-4f8cd6078fa8@gmail.com>
 <e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com>
 <cea1929d-44cb-4d60-aae9-2df894add108@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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