Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130413
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 22 Mar 2026 13:19:33 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@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. :-)
>
> -- 
>   Larry Garfield
>   larry@garfieldtech.com

Hi folks, and welcome back!

Arnaud and I have made a number of changes to the RFC that should make it sleaker and more consistent.  The notable ones (that impact behavior) are as follows:

1. We went back and forth on the `continue` question several times, before coming to the conclusion that `continue` is a tool for looping structures only.  That `switch` also uses it is just `switch` being silly because reasons, and there is no reason `using` must inherit its weirdness.  Therefore, `continue` inside a `using` block now means nothing at all.  `continue` will ignore it, the same way it ignores an `if` statement.

2. Several people (including us) were uncomfortable with using a boolean return from the exitContext() method.  While that is what Python does, it is indeed not self-evident how it works.  (Should true mean "true, I'm done" or "true, rethrow"?)  We debated using an enum value, but that appeared to be too verbose.

Instead, we decided that exitContext() should return ?Throwable, which is the same thing it is passed.  In a success case, it is passed null.  In a failure case, it is passed a throwable.  So it can then return null (meaning "we're done, nothing else to do here") or a throwable, which will then get thrown.  Since in most cases an error should be allowed to propagate, it means simply calling `return $exception` at the end of the method will "do the right thing" 95% of the time.  Simple and easy and self-documenting.  (If there's a reason to wrap and rethrow the exception, do that and return the new exception.  Or to swallow the exception and not propagate it, return null.)

We believe this concludes the context manager design.  We're pretty happy with where it is at this point.  Baring any further substantive feedback, we'll open the vote in a little over 2 weeks.

--Larry Garfield