Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129086
Content-Type: multipart/alternative; boundary=Apple-Mail-4CA3F072-C252-4512-B541-F2AC2B638BDE
Content-Transfer-Encoding: 7bit
Precedence: list
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [RFC] Context Managers
Date: Wed, 5 Nov 2025 01:25:14 -0800
Message-ID: <066080FD-0190-4067-94BB-E25D538167DF@daveyshafik.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
In-Reply-To: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
From: me@daveyshafik.com (Davey Shafik)


--Apple-Mail-4CA3F072-C252-4512-B541-F2AC2B638BDE
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Nov 4, 2025, at 12:18, Larry Garfield <larry@garfieldtech.com> wrote:
>=20
> =EF=BB=BFArnaud and I would like to present another RFC for consideration:=
 Context Managers.
>=20
> https://wiki.php.net/rfc/context-managers
>=20
> You'll probably note that is very similar to the recent proposal from Tim a=
nd Seifeddine.  Both proposals grew out of casual discussion several months a=
go; I don't believe either team was aware that the other was also actively w=
orking 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.  In part=
icular, as Arnaud noted in an earlier reply, __destruct() is unreliable if t=
iming matters.  It also does not allow differentiating between a success or f=
ailure exit condition, which for many use cases is absolutely mandatory (as s=
hown in the examples in the context manager RFC).
>=20
> The Context Manager proposal is a near direct port of Python's approach, w=
hich is generally very well thought-out.  However, there are a few open ques=
tions as listed in the RFC that we are seeking feedback on.
>=20
> Discuss. :-)

Larry, Arnaud,

I really like this RFC but have a couple of things to discuss:

- automatically re-throwing exceptions: I think that this behavior, especial=
ly with a boolean return value deciding if it happens or not is not intuitiv=
e. I think a better approach is to do nothing with the exception and let the=
 user re-throw it if desired. I can't think of anywhere else we re-throw exc=
eptions unless the user indicates otherwise. I'd rather leave the return val=
ue for return values; we could expand this allow access to the return value l=
ike: with (foo() as $foo return $bar) { }, and $bar would be set to null on v=
oid returns.

-  context variable and scope: I know that you explicitly are not creating a=
 new scope, this means that the context variable will clash with the enclosi=
ng scope namespace, and then the variable will be unset after the context en=
ds, this doesn't sit so well with me. I think I'd rather see the same behavi=
or as arrow function arguments, where it does not override variables of the s=
ame name in the enclosing scope and whatever value it has is lost at the end=
 of the context, leaving the outer scope version intact.

At worst though, I'm sure IDE and static analyzers will be able to detect th=
e "use after unset" behavior with clashing variable names, causing the devel=
oper to resolve it, and it'll be fine either way.

Thanks for the great RFC!

- Davey=20



--Apple-Mail-4CA3F072-C252-4512-B541-F2AC2B638BDE
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html class=3D"apple-mail-supports-explicit-dark-mode"><head><meta http-equi=
v=3D"content-type" content=3D"text/html; charset=3Dutf-8"></head><body dir=3D=
"auto"><div dir=3D"ltr"><div style=3D"direction: inherit;"><br></div></div><=
div dir=3D"ltr"><blockquote type=3D"cite">On Nov 4, 2025, at 12:18, Larry Ga=
rfield &lt;larry@garfieldtech.com&gt; wrote:<br><br></blockquote></div><bloc=
kquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>Arnaud and I would like=
 to present another RFC for consideration: Context Managers.</span><br><span=
></span><br><span>https://wiki.php.net/rfc/context-managers</span><br><span>=
</span><br><span>You'll probably note that is very similar to the recent pro=
posal from Tim and Seifeddine. &nbsp;Both proposals grew out of casual discu=
ssion several months ago; I don't believe either team was aware that the oth=
er was also actively working on such a proposal, so we now have two. &nbsp;C=
'est la vie. :-)</span><br><span></span><br><span>Naturally, Arnaud and I fe=
el that our approach is the better one. &nbsp;In particular, as Arnaud noted=
 in an earlier reply, __destruct() is unreliable if timing matters. &nbsp;It=
 also does not allow differentiating between a success or failure exit condi=
tion, which for many use cases is absolutely mandatory (as shown in the exam=
ples in the context manager RFC).</span><br><span></span><br><span>The Conte=
xt Manager proposal is a near direct port of Python's approach, which is gen=
erally very well thought-out. &nbsp;However, there are a few open questions a=
s listed in the RFC that we are seeking feedback on.</span><br><span></span>=
<br><span>Discuss. :-)</span><br></div></blockquote><br><div>Larry, Arnaud,<=
/div><div><br></div><div>I really like this RFC but have a couple of things t=
o discuss:</div><div><br></div><div>- automatically re-throwing exceptions: I=
 think that this behavior, especially with a boolean return value deciding i=
f it happens or not is not intuitive. I think a better approach is to do not=
hing with the exception and let the user re-throw it if desired. I can't thi=
nk of anywhere else we re-throw exceptions unless the user indicates otherwi=
se. I'd rather leave the return value for return values; we could expand thi=
s allow access to the return value like: with (foo() as $foo return $bar) { }=
, and $bar would be set to null on void returns.</div><div><br></div><div>- &=
nbsp;context variable and scope: I know that you explicitly are not creating=
 a new scope, this means that the context variable will clash with the enclo=
sing scope namespace, and then the variable will be unset after the context e=
nds, this doesn't sit so well with me. I think I'd rather see the same behav=
ior as arrow function arguments, where it does not override variables of the=
 same name in the enclosing scope and whatever value it has is lost at the e=
nd of the context, leaving the outer scope version intact.</div><div><br></d=
iv><div>At worst though, I'm sure IDE and static analyzers will be able to d=
etect the "use after unset" behavior with clashing variable names, causing t=
he developer to resolve it, and it'll be fine either way.</div><div><br></di=
v><div>Thanks for the great RFC!</div><div><br></div><div>- Davey&nbsp;</div=
><div><br></div><div><br></div></body></html>=

--Apple-Mail-4CA3F072-C252-4512-B541-F2AC2B638BDE--