Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130639
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 15 Apr 2026 09:52:17 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a748c98a-180a-475f-93a7-b802c21138e2@app.fastmail.com>
In-Reply-To: <cf6ac562-7e6f-4eca-a514-6aa3c9692461@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <4985896b-c80a-4302-912e-9f572a260fb5@app.fastmail.com>
 <cf6ac562-7e6f-4eca-a514-6aa3c9692461@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 14, 2026, at 9:27 AM, Rob Landers wrote:
> On Tue, Apr 14, 2026, at 16:18, Rob Landers wrote:
>>=20
>>=20
>> On Tue, Nov 4, 2025, at 21:13, Larry Garfield wrote:
>>> Arnaud and I would like to present another RFC for consideration: Co=
ntext Managers.
>>>=20
>>> https://wiki.php.net/rfc/context-managers
>>>=20
>>> You'll probably note that is very similar to the recent proposal fro=
m Tim and Seifeddine.  Both proposals grew out of casual discussion seve=
ral 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. :-)
>>>=20
>>> Naturally, Arnaud and I feel that our approach is the better one.  I=
n particular, as Arnaud noted in an earlier reply, __destruct() is unrel=
iable if timing matters.  It also does not allow differentiating between=
 a success or failure exit condition, which for many use cases is absolu=
tely mandatory (as shown in the examples in the context manager RFC).
>>>=20
>>> The Context Manager proposal is a near direct port of Python's appro=
ach, 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.
>>>=20
>>> Discuss. :-)
>>>=20
>>> --=20
>>>   Larry Garfield
>>>   larry@garfieldtech.com
>>>=20
>>=20
>> Hi Larry/Arnaud,
>>=20
>> This is a pretty exciting thread and fascinating proposal. That being=
 said, I have a couple of subtle questions that don't seem to be answere=
d in the (very long) thread or the RFC itself -- If I missed it, please =
let me know:

>>  1.  What happens if a Fiber is suspended in the using block and neve=
r resumed? When is the using block released to clean up the context?

Since it decomposes to a try-catch-finally, it will exit whenever the fi=
nally block would have run if you'd just typed out try-catch-finally you=
rself.  Arnaud checked, and confirmed that when the fiber is destroyed t=
he using block will exit in a success case (ie, exitContext(null)).

>>  2. There's still no mention of how this should affect debugging, wil=
l we see the "desugared" or "sugared" version? Is that even a concern fo=
r the RFC?

Error messages would see the original code, so "error on line X" would b=
e based on the original `using` block.  That's the same as any other des=
ugaring we already do.  (PIpes, PFA, constructor promotion, etc.)  Debug=
gers will see the materialized opcodes, again, the same other desugaring=
 cases.

>>  3. I will say it is weird to have exitContext return an exception; b=
ut what happens if an exception is thrown during exitContext? Why not ju=
st have it return void and throw if you need to throw instead of having =
two paths to the same thing?

There's a subtle but important difference here: An exception passed thro=
ugh exitContext() is the original exception from lower in the call stack=
, and its backtrace will be the original location of the error.  An exce=
ption thrown from within exitContext() itself indicates a failure that t=
he Context Manager is responsible for, usually an error in the exitConte=
xt() logic itself.

Technically a Context Manager can wrap-and-rethrow the exception if it w=
ants, but then it is "claiming ownership" over it, just like in any othe=
r case of wrap-and-rethrow.

Our expectation is that 90% of the time, "let the exception propagate up=
 unimpeded" is the desired behavior.  This approach makes "return $e" th=
e right thing to do almost-always, which is nice and simple to remember.

See the "return values and exception handling" section for a discussion =
of this in more detail.  As I said in a previous reply, our constraints =
are different than Python's so we end up with a different solution.  If =
you have a suggestion for an alternate approach to the problem, we're ha=
ppy to listen.

>>  4. Looking at the desugared form ... I'm a bit confused: if exitCont=
ext is called during the finally path and returns an exception, it is ju=
st swallowed? But if it is thrown, it won't be?

The finally path is only reached in case of a successful exit.  Therefor=
e there is no exception to pass in, and thus returning an exception is m=
eaningless.  If exitContext() throws a new exception of its own (which w=
ould indicate an error in its own logic), that  will just bubble up past=
 the `using` block entirely, which is what we want.

>>  5. That being said, I don't think the RFC shares with us when we sho=
uld return an exception vs. throw an exception.

See the "return values and exception handling" section.  If something th=
ere isn't clear, let me know and I will try to clarify further.

>> =E2=80=94 Rob
>
> Maybe the desugared version should look more like this?
>
> } catch (\Throwable $e) {
>     try {
>         $__mgr->exitContext($e);
>     } catch (\Throwable $cleanupException) {
>         throw new ContextManagerException(
>             $cleanupException->getMessage(),
>             previous: $e
>         );
>     }
>     throw $e;
> }
>

I'm not sure I see a reason to force any new exceptions to be only of th=
e ContextManagerException type.  If there's a TypeError inside exitConte=
xt() or something, I'd expect that to be propagated as a TypeError.

--Larry Garfield