Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129600
Precedence: list
MIME-Version: 1.0
References: <CAFyg4HhrzQrE-q8D6WVkyq9tY+hzR=8rXiXLDPYpNKdYeydrVA@mail.gmail.com>
 <1F3473C7-5D83-48D3-964E-A63D6F44D21E@rwec.co.uk> <4998b4c6-0474-4f0c-b63a-9909b8acfa96@bastelstu.be>
 <a898d9a0-21c1-467d-9f12-f540b43705c8@rwec.co.uk> <018421f64342a0d960589b4c8eea5cc5@bastelstu.be>
 <84b9dc16-3eb3-4283-b015-3af29fc0e55d@rwec.co.uk> <ac6647018284df523300b427e19cf097@bastelstu.be>
 <590fa655-d170-43f2-984c-d0a5ff6c30e4@bastelstu.be> <7c623161-cde3-4fc0-944c-ddfc2785c845@rwec.co.uk>
 <afd9e2ff528604700625f98e4db0a4a9@bastelstu.be> <21f12343-b212-456f-93b3-079810d3d76d@rwec.co.uk>
 <b73c31e5-fb10-4899-bdb7-bf4cd0c4611f@app.fastmail.com>
In-Reply-To: <b73c31e5-fb10-4899-bdb7-bf4cd0c4611f@app.fastmail.com>
Date: Sat, 13 Dec 2025 10:18:43 +0700
Message-ID: <CAEZPtU4BZhj7Xb4Sq0kxJVE8v8i4EceqEpZnjMWA5jjp8SjGtg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: pierre.php@gmail.com (Pierre Joye)

Hello,

On Sat, Dec 13, 2025 at 6:10=E2=80=AFAM Larry Garfield <larry@garfieldtech.=
com> wrote:

> The more I think on this, the more I think that the auto-unsetting behavi=
or of a `let` would be useful *only* in combination with some other existin=
g block, not as its own block.
>
> if (let $x=3Dstuff(); $x < 1) { ... }
>
> for (let $i =3D 0; $i < 10; $i++) { ... }
>
> foreach (let $arr as $k =3D>v) { ... } (applies to both $k and $v)
>
> And so on.  (I'm not sure if it makes sense on a while?  Possibly.)  Exac=
t syntax above is just spitballing.

I remain skeptical about adding block scoping to PHP at all, but if we
do pursue this, I have concerns about the approach. I have been
working on some tools I need and spent quite some time on php scoping
at large, and in detail, that's mainly the reason I am jumping in for
a change.

My primary concern with the suggestions of integrating let into
existing control structures (if (let $x=3Dstuff(); ...), for (let $i =3D
0; ...)) is ambiguity. The same for sequence-like syntax proposed
earlier. PHP doesn't currently have block scoping, and introducing it
in a way that reuses or resembles existing syntax patterns will be
difficult to distinguish from current behavior. This could create
hidden bugs that could be hard to catch. Without talking about
changing let to "semi" reserved word. Not sure what that means tho'.
:)

The 'using' syntax proposed earlier in this thread, mapping maybe the
'with' behavior may also provide such an unambiguous definition.

If we add block scoping, it needs to be extremely explicit and
unambiguous. The RFC's current syntax does achieve this. Alternative
syntaxes like using (potentially mapping to with behavior) might also
provide that clarity, whereas let integrated into control structures
may not.

I am also wondering about the actual need of having a block only
scope, and potentially for some variables only (if that's part of the
behaviors as well). When a scope is needed but one does not want to
define a separate function, closure and co are cheap now. But I may
miss some obvious benefits that could benefit from such additions.
That would be a great addition to the RFC, actual use cases and
benefits over alternative existing ways to do it. Almost all other
languages provide block scoping, except bash (nice friend here ;), but
it does not mean we have to go that way. If we do, I emphasize again,
it needs to be extremely explicit.

PS: If we were back to php2/3, heh, even 4, I would propose to simply
introduce block scoping in full, that would have been a more standard
approach. But time flies, and we are at php 8 and it is tricky to
introduce this at this stage :)

In short, If we do proceed, explicitness must be non-negotiable :)

best,
--=20
Pierre

@pierrejoye | http://www.libgd.org