Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130631
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 14 Apr 2026 16:18:11 +0200
To: internals@lists.php.net
Message-ID: <4985896b-c80a-4302-912e-9f572a260fb5@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: multipart/alternative;
 boundary=9558b9f8b29f8f0508ae6b289e02ef6115312687
From: rob@bottled.codes ("Rob Landers")

--9558b9f8b29f8f0508ae6b289e02ef6115312687
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Nov 4, 2025, at 21:13, Larry Garfield wrote:
> Arnaud and I would like to present another RFC for consideration: Cont=
ext Managers.
>=20
> https://wiki.php.net/rfc/context-managers
>=20
> You'll probably note that is very similar to the recent proposal from =
Tim and Seifeddine.  Both proposals grew out of casual discussion severa=
l months ago; I don't believe either team was aware that the other was a=
lso actively working on such a proposal, so we now have two.  C'est la v=
ie. :-)
>=20
> Naturally, Arnaud and I feel that our approach is the better one.  In =
particular, as Arnaud noted in an earlier reply, __destruct() is unrelia=
ble if timing matters.  It also does not allow differentiating between a=
 success or failure exit condition, which for many use cases is absolute=
ly mandatory (as shown in the examples in the context manager RFC).
>=20
> The Context Manager proposal is a near direct port of Python's approac=
h, which is generally very well thought-out.  However, there are a few o=
pen questions as listed in the RFC that we are seeking feedback on.
>=20
> Discuss. :-)
>=20
> --=20
>   Larry Garfield
>   larry@garfieldtech.com
>=20

Hi Larry/Arnaud,

This is a pretty exciting thread and fascinating proposal. That being sa=
id, I have a couple of subtle questions that don't seem to be answered i=
n 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 never r=
esumed? When is the using block released to clean up the context?
 2. There's still no mention of how this should affect debugging, will w=
e see the "desugared" or "sugared" version? Is that even a concern for t=
he RFC?
 3. I will say it is weird to have exitContext return an exception; but =
what happens if an exception is thrown during exitContext? Why not just =
have it return void and throw if you need to throw instead of having two=
 paths to the same thing?
 4. Looking at the desugared form ... I'm a bit confused: if exitContext=
 is called during the finally path and returns an exception, it is just =
swallowed? But if it is thrown, it won't be?
 5. That being said, I don't think the RFC shares with us when we should=
 return an exception vs. throw an exception.

=E2=80=94 Rob
--9558b9f8b29f8f0508ae6b289e02ef6115312687
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Tue, Nov 4, 2025, at 21:13, Larry Garfield wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Arnaud and I wou=
ld like to present another RFC for consideration: Context Managers.</div=
><div><br></div><div><a href=3D"https://wiki.php.net/rfc/context-manager=
s">https://wiki.php.net/rfc/context-managers</a></div><div><br></div><di=
v>You'll probably note that is very similar to the recent proposal from =
Tim and Seifeddine.&nbsp; Both proposals grew out of casual discussion s=
everal 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.&nbsp; =
C'est la vie. :-)</div><div><br></div><div>Naturally, Arnaud and I feel =
that our approach is the better one.&nbsp; In particular, as Arnaud note=
d in an earlier reply, __destruct() is unreliable if timing matters.&nbs=
p; It also does not allow differentiating between a success or failure e=
xit condition, which for many use cases is absolutely mandatory (as show=
n in the examples in the context manager RFC).</div><div><br></div><div>=
The Context Manager proposal is a near direct port of Python's approach,=
 which is generally very well thought-out.&nbsp; However, there are a fe=
w open questions as listed in the RFC that we are seeking feedback on.</=
div><div><br></div><div>Discuss. :-)</div><div><br></div><div>--&nbsp;</=
div><div>&nbsp; Larry Garfield</div><div>&nbsp;&nbsp;<a href=3D"mailto:l=
arry@garfieldtech.com">larry@garfieldtech.com</a></div><div><br></div></=
blockquote><div><br></div><div>Hi Larry/<span class=3D"color" style=3D"c=
olor:rgb(51, 51, 51);">Arnaud,</span></div><div><br></div><div><span cla=
ss=3D"color" style=3D"color:rgb(51, 51, 51);">This is a pretty exciting =
thread and fascinating proposal. That being said, I have a couple of sub=
tle questions that don't seem to be answered in the (very long) thread o=
r the RFC itself -- If I missed it, please let me know:</span><br></div>=
<ol><li>&nbsp;What happens if a Fiber is suspended in the using block an=
d never resumed? When is the using block released to clean up the contex=
t?</li><li>There's still no mention of how this should affect debugging,=
 will we see the "desugared" or "sugared" version? Is that even a concer=
n for the RFC?</li><li>I will say it is weird to have exitContext return=
 an exception; but what happens if an exception is thrown during exitCon=
text? Why not just have it return void and throw if you need to throw in=
stead of having two paths to the same thing?</li><li>Looking at the desu=
gared form ... I'm a bit confused: if exitContext is called during the f=
inally path and returns an exception, it is just swallowed? But if it is=
 thrown, it won't be?</li><li>That being said, I don't think the RFC sha=
res with us when we should return an exception vs. throw an exception.<b=
r></li></ol><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div><=
/body></html>
--9558b9f8b29f8f0508ae6b289e02ef6115312687--