Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129919
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 25 Jan 2026 12:40:12 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <ebd6529c-0fd5-4f17-8ca6-1847094e7fa5@app.fastmail.com>
In-Reply-To: <a5117dfcb4549a09f42556c5365fbb79@bastelstu.be>
References: <3665e8eb-db54-421b-8ffe-e3b1902caf09@app.fastmail.com>
 <48689ab4ab0bb680ff9457e406490fa5@bastelstu.be>
 <3afc1bd6-7515-4ae7-a2d4-dd4e08917746@app.fastmail.com>
 <a5117dfcb4549a09f42556c5365fbb79@bastelstu.be>
Subject: Re: [PHP-DEV] Re: [VOTE] let construct (Block Scoping)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jan 24, 2026, at 12:16 PM, Tim D=C3=BCsterhus wrote:

> My understanding the initial paragraph of your email is that the entir=
e=20
> functionality of the block scoping RFC could be included in the Contex=
t=20
> Manager RFC. The Context Manager RFC uses the same "high-level" syntax=20
> of having a dedicated block for declarations - just using `using`=20
> instead of `let` as the keyword and using `=3D>` instead of `=3D` for =
an=20
> assignment (the latter of which was considered confusing in the=20
> discussion). I'm sure I must be misunderstanding, because I don't foll=
ow=20
> how the syntax of this RFC is "non-standard and clumsy" without this=20
> equally applying to the context manager RFC. Can you rephrase?

Block scoping and CMs are related and overlap, but are different things.=
 =20

`let`, in every language I am aware of that uses it, is an inline part o=
f the variable declaration, and then they do something to resolve the "d=
ead zone" question.  Languages that have block scoping have had it from =
the beginning, so "variable dies at the next }" is built into the langua=
ge semantics and development culture.  Neither is true in PHP.  So havin=
g a block-esque syntax for "only these special blocks and these special =
variables get block scoping" is something I have never seen before, and =
feels very clumsy.

CMs are about packaging up setup/teardown logic to make them reusable, a=
nd therefore more ergonomic.  That setup/teardown can and often does inc=
lude unsetting variables, but that's not its main purpose.  It's just an=
 implementation detail.  In every language with such functionality, it i=
s a block level construct.

Block scoping as presented here is essentially a "junior, limited CM", w=
ith a future scope of adding a Disposable interface to make it a less-li=
mited CM.  I fundamentally believe that is the wrong way around, and hav=
e already discussed elsewhere (I think) why forcing the context manager =
(packaged logic) and context variable (the variable(s) that will need cl=
eanup) to be the same value is fundamentally limiting and flawed.

I proposed allowing the `using` syntax to handle non-CM objects specific=
ally to incorporate the "degenerate case" where unsetting is the only me=
aningful teardown, and thereby avoid the need for a boilerplate new Just=
UnsetTheThing($thing) for the degenerate cases.  CMs can also return $th=
is from enterContext() if appropriate, which would then have the same ef=
fect as the Disposable interface.

So no matter how you slice it, having a separate CM from context variabl=
e provides more flexibility than the proposed `let` syntax, in a consist=
ent and unified fashion.  By tweaking CMs, we can allow it to also cover=
 the simple, degenerate cases that block scoping handles in addition to =
the more robust options it naturally supports.

> I'd also like to note that it was an explicit design goal of the block=20
> scoping RFC to compose nicely with existing control structures to be=20
> generically applicable. This enables several of the example use cases=20
> listed in the RFC. The context manager RFC requires braces and a=20
> proposed special case for `try` instead of just accepting any statemen=
t=20
> like block scoping does. Due to its composibility, the block scoping R=
FC=20
> is even compatible with future additions to the language (provided the=20
> future additions follow the established syntax). As an example, patter=
n=20
> matching comes to mind as another way of "writing into variables". Blo=
ck=20
> scoping will just work with match:
>
>      let ($x, $y) $result =3D match ($p) is {
>          Point(:$z, :$x, y: 4) =3D> "x is $x, y is 4, z is $z",
>      };
>
> to prevent $x and $y from leaking out of the `match()`. And similarly =
to=20
> the `foreach()` future scope, we could allow `match ($p) let is` to=20
> automatically block scope all variables bound by the pattern.

thinking_face.gif

This is sort of what we were trying to noodle through with the questions=
 about expression-oriented `using`, but it didn't stick.  I would have t=
o talk to Arnaud, but I suppose it's probably possible to allow `using` =
to work on an arbitrary construct and inherit its block.  I'm quite open=
 to discussing the feasibility of that.

It's really unfortunate that both proposals were worked on separately, a=
s I do believe there are good ideas in both.  But I would much rather wo=
rk from the more-flexible design and then short-cut the degenerate cases=
, as that gives, I believe, a better outcome in the end.

--Larry Garfield