Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129799
Feedback-ID: id5114917:Fastmail
Message-ID: <323651a4-f4c5-4a93-bddb-0986bf01eef8@rwec.co.uk>
Date: Tue, 20 Jan 2026 22:26:44 +0000
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
To: internals@lists.php.net
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>
 <7da06511e359f73410032a03757dfbe4@bastelstu.be>
Content-Language: en-GB
In-Reply-To: <7da06511e359f73410032a03757dfbe4@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 17/12/2025 19:09, Tim Düsterhus wrote:
> The difference I'm seeing is that for languages where variable 
> declarations (and block scoping) are a core part of the language, the 
> scoping rules are “moulding” (if that word makes sense here) how code 
> in that language is written and how folks reason about the code. This 
> is different for a language where block scoping is added 
> after-the-fact and remains an optional part of the language.


I can sort of see where you're coming from, but counter-examples include 
Perl and JS, both of which treat declarations as optional, and innovated 
new variants of them, but stuck to the "ALGOL-style" syntax.


>>> I feel that the C99 requirements and syntax would still have more 
>>> ambiguity compared to the proposed `let()` syntax in cases like this:
>>>
>>>     {
>>>         let $foo = bar($baz); // What is $baz referring to? 
>>> Particularly if it is a by-reference out parameter.
>>>
>>>         let $baz = 1;
>>>     }


As discussed on the other thread, this part of the discussion turns out 
be moot, because exactly the same ambiguity exists in the proposed syntax:

let($foo = bar($baz), $baz=1) { ... }

The syntax alone doesn't tell you what that will do, only knowing the 
choices made in the RFC.



>>> PHP already limits where "goto" can jump to; I don't know how that's 
>>> implemented, but I don't think we need to get into philosophical 
>>> definitions to say "you can't jump into the middle of a declaration 
>>> list".
>
> Another, perhaps better, example that is not handled well by any 
> C-derived language that we are aware of is block scoping in 
> combination with `switch()`


Compile Error: 'let' declarations whose closest block is a 'switch' are 
forbidden.

Problem solved.



> Other languages have other ecosystems and other user expectations. PHP 
> has extensive “scope introspection” functionality by means of 
> `extract()`, `compact()`, `get_defined_vars()` and variable variables. 
> Folks are used to being able to access arbitrary variables (it's just 
> a Warning, not an Error to access undefined variables) and there's 
> also constructs like `isset()` that can act on plain old local-scope 
> variables. Adding semantics like the “temporal dead zone” from 
> JavaScript that you suggested in the other thread would mean that we 
> would need to have entirely new semantics and interactions with 
> various existing language features that folks already know, adding to 
> the complexity of the language.


I don't think most of these would need special semantics at all. If it's 
an error to read from $foo, it follows that it's an error to read from 
$$x when $x is 'foo', and an error to run compact('foo').

It seems equally obvious to me that get_defined_vars() would omit the 
variable, and isset() would return false.

There might be some nuances to the implementation, but I imagine it 
would be similar to uninitialized object properties: a sentinel value in 
the zval, and checks for that sentinel in suitable places.


I don't know JS well enough to name them, but I bet the ECMA committee 
had to consider similar features, and most users simply never encounter 
them.



> For me this works, because the `let()` is preparing me that “this code 
> is doing user processing” and the `if()` is just an “implementation 
> detail” / “means to an end” of that. By the block scoping semantics I 
> know that when I read the closing brace, the user processing is 
> finished. The function is a <h1>, the user processing is a <h2> and 
> the `if()` is a <h3> if that analogy makes sense. If I just want to 
> get an overview over the function, I only care about the <h2> headings.


I can't think of any situation where "this block of code contains a 
scoped variable" is more important information than "this block of code 
might not run at all".

In the analogy, I would always class an if() as an h2; it's one of the 
most fundamental pieces of control flow.


> I understand that some languages have postfix conditions, but being 
> able to place an `if()` after another control structure is not a new 
> thing. The same would apply to:
>
>     foreach ($users as $user) if ($user->isAdmin()) {
>         echo "User is admin";
>     }
>
> which is already valid PHP.


That syntax would never occur to me, and if I saw it, I'd immediately 
add the "missing" braces.



> The comma would leave ambiguity in cases like `if (let $repository = 
> $container->getRepository(), $user = $repository->find(1))`. 


I think you missed the context: in Perl, the comma isn't part of the 
"if" or "let", it's just a general purpose operator, so this ambiguity 
is just the precedence of "," vs "my".


> That's probably why C++ uses the `;` as a delimiter there.


But sure, that works too. I was just exploring possibilities.





I think, in a nutshell, this is where we have opposing opinions:


> we believe the “top of the block” semantics are important for block 
> scoping to work well in PHP due to its unique semantics and 30y history.


I believe using familiar declaration syntax is important for block 
scoping to work well in PHP due to its strong similarity to other 
languages in the ALGOL-C-Java family, and the 65 year history of that 
family.


-- 
Rowan Tommins
[IMSoP]