Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129913
Precedence: list
MIME-Version: 1.0
Date: Sat, 24 Jan 2026 19:16:19 +0100
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [VOTE] let construct (Block Scoping)
In-Reply-To: <3afc1bd6-7515-4ae7-a2d4-dd4e08917746@app.fastmail.com>
References: <3665e8eb-db54-421b-8ffe-e3b1902caf09@app.fastmail.com>
 <48689ab4ab0bb680ff9457e406490fa5@bastelstu.be>
 <3afc1bd6-7515-4ae7-a2d4-dd4e08917746@app.fastmail.com>
Message-ID: <a5117dfcb4549a09f42556c5365fbb79@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2026-01-23 16:47, schrieb Larry Garfield:
> As currently written, yes.  However, as noted previously in the Context 
> Manager thread we are open to allowing arbitrary values in the CM 
> position, which would fall back to just using that value and then 
> unsetting it.  That would effectively replace the `let` syntax entirely 
> with a unified 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.

For these two I refer to the email I just sent in reply to Arnaud. I 
believe that 4 example use cases are by no means an indication of an RFC 
being limited in usefulness. Block scoping is a well-established feature 
in programming languages and I'm positive that folks will be able to 
come up with even more examples of where block scoping would have been 
helpful to them to avoid bugs / make their code easier to reason about.

> * The syntax is far too non-standard and clumsy.

My understanding the initial paragraph of your email is that the entire 
functionality of the block scoping RFC could be included in the Context 
Manager RFC. The Context Manager RFC uses the same "high-level" syntax 
of having a dedicated block for declarations - just using `using` 
instead of `let` as the keyword and using `=>` instead of `=` for an 
assignment (the latter of which was considered confusing in the 
discussion). I'm sure I must be misunderstanding, because I don't follow 
how the syntax of this RFC is "non-standard and clumsy" without this 
equally applying to the context manager RFC. Can you rephrase?

> * Expanding CMs to fully encompass the behavior of this RFC is trivial, 
> which would avoid redundant and confusing syntax.

The same is true the other way around, possible ideas are listed in the 
Future Scope.

I'd also like to note that it was an explicit design goal of the block 
scoping RFC to compose nicely with existing control structures to be 
generically applicable. This enables several of the example use cases 
listed in the RFC. The context manager RFC requires braces and a 
proposed special case for `try` instead of just accepting any statement 
like block scoping does. Due to its composibility, the block scoping RFC 
is even compatible with future additions to the language (provided the 
future additions follow the established syntax). As an example, pattern 
matching comes to mind as another way of "writing into variables". Block 
scoping will just work with match:

     let ($x, $y) $result = match ($p) is {
         Point(:$z, :$x, y: 4) => "x is $x, y is 4, z is $z",
     };

to prevent $x and $y from leaking out of the `match()`. And similarly to 
the `foreach()` future scope, we could allow `match ($p) let is` to 
automatically block scope all variables bound by the pattern.

Best regards
Tim Düsterhus