Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129754
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 13 Jan 2026 16:19:45 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <905d9879-70ef-4c87-8578-26519c6d4818@app.fastmail.com>
In-Reply-To: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Nov 4, 2025, at 2:13 PM, Larry Garfield wrote:
> Arnaud and I would like to present another RFC for consideration: 
> Context Managers.
>
> https://wiki.php.net/rfc/context-managers
>
> You'll probably note that is very similar to the recent proposal from 
> Tim and Seifeddine.  Both proposals grew out of casual discussion 
> several months ago; I don't believe either team was aware that the 
> other was also actively working on such a proposal, so we now have two. 
>  C'est la vie. :-)
>
> Naturally, Arnaud and I feel that our approach is the better one.  In 
> particular, as Arnaud noted in an earlier reply, __destruct() is 
> unreliable if timing matters.  It also does not allow differentiating 
> between a success or failure exit condition, which for many use cases 
> is absolutely mandatory (as shown in the examples in the context 
> manager RFC).
>
> The Context Manager proposal is a near direct port of Python's 
> approach, which is generally very well thought-out.  However, there are 
> a few open questions as listed in the RFC that we are seeking feedback 
> on.
>
> Discuss. :-)

Hi folks.  The holidays are over, so we're back on Context Managers.

There are three questions outstanding, 2 of which we want feedback on before we can finalize for a vote.

1. Discussing between us, Arnaud and I aren't confident in expression-based `using`.  It would necessitate a trailing semicolon in all cases, and while we have ideas for the return value there's nothing that has clear and indisputable benefit.  So we're going to drop this one unless anyone wants to make a strong case for it.

2. The syntax bikeshed.  Right now, what we have in the RFC is `using (new CM() => $var)`.  We feel that's sufficiently self-descriptive for "produces".  However, there was some pushback on that and we're still open to other ideas here.  The critera would be "clear, unambiguous, and easy to type".  If there's no clear consensus, we'll probably stick with `=>`.

3. One idea we've discussed internally is allowing non-context-manager objects in the `using` statement.  If the left-side value in `using` is a non-CM, then it will itself be used as the context variable.  It would still get unset at the end of the block, so if simply unsetting it is sufficient cleanup it would eliminate the need for a wrapper.  This would remove the need for special casing of `resource` variables, and would also, in effect, absorb the behavior of the block scoping `let` proposal.  The block scoping behavior becomes a degenerate case of `using`, feeding two birds with one bird feeder.  (To be more animal friendly.)

I'm open to that idea, though Arnaud doesn't like it on the grounds that it could be too confusing for folks.  So we're putting it out to see if there is a consensus on it.


Once those issues are addressed, I think we're nearly able to take CMs to a vote.  (If anyone else wants to weigh in on some other part as well, even if it's just a voice of support/approval, now is the time.)

Cheers.

--Larry Garfield