Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129895
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 23 Jan 2026 09:47:16 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <3afc1bd6-7515-4ae7-a2d4-dd4e08917746@app.fastmail.com>
In-Reply-To: <48689ab4ab0bb680ff9457e406490fa5@bastelstu.be>
References: <3665e8eb-db54-421b-8ffe-e3b1902caf09@app.fastmail.com>
 <48689ab4ab0bb680ff9457e406490fa5@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 Fri, Jan 23, 2026, at 2:20 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2026-01-23 00:29, schrieb Joseph Leedy:
>> While I appreciate all of the hard work that Seifeddine and you put=20
>> into this RFC, Tim, if I had the power to vote, I would vote "No" on=20
>> this RFC as I like the approach laid out in the Context Manager RFC=20
>> much better.. Thank you both!
>
> I'd like to note that while the two RFCs share some of the scope,=20
> neither is a direct replacement of the other. I think Rowan previously=20
> summarized it well in this email:=20
> https://news-web.php.net/php.internals/129630.

As currently written, yes.  However, as noted previously in the Context =
Manager thread we are open to allowing arbitrary values in the CM positi=
on, which would fall back to just using that value and then unsetting it=
.  That would effectively replace the `let` syntax entirely with a unifi=
ed syntax.

I have also voted No on this RFC, for many of the reasons already stated:

* The functionality is too limited.
* The functionality is inherently unreliable due to value escape.
* The syntax is far too non-standard and clumsy.
* Expanding CMs to fully encompass the behavior of this RFC is trivial, =
which would avoid redundant and confusing syntax.

--Larry Garfield