Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129841
Precedence: list
MIME-Version: 1.0
Date: Thu, 22 Jan 2026 10:08:55 +0100
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
In-Reply-To: <323651a4-f4c5-4a93-bddb-0986bf01eef8@rwec.co.uk>
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>
 <323651a4-f4c5-4a93-bddb-0986bf01eef8@rwec.co.uk>
Message-ID: <a99fa19d456261296804ea0fd82edf4f@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-20 23:26, schrieb Rowan Tommins [IMSoP]:
> 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.

Yes, syntax alone does not give you any guarantees. But it provides an 
indication of which possible choice is more likely to be made. That's 
also why I tried to emphasize and explain how the different syntax works 
with my intuition (e.g. by using “suggests” or “strongly suggests” as 
the phrasing). You may disagree of course. Different brains work 
differently and different experiences with different programming 
languages probably also shape how one reasons about the code.

>> 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').

I could've probably phrases it more clearly: I don't think the existence 
of a temporal dead zone is a good idea for PHP. I find it especially 
unexpected to be disallowed to write to a variable (i.e. more extract() 
rather than compact()).

>> 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".

Note that the quoted wording said “this code deals with user processing” 
not “this block contains a scoped variable”. The variable *name* is 
important information there and knowing that this variable name will not 
be used after the block is important to me, because then I know that 
user processing is finished.

> In the analogy, I would always class an if() as an h2; it's one of the 
> most fundamental pieces of control flow.

How the user is being processed (e.g. conditionally) is then the h3.

> I think, in a nutshell, this is where we have opposing opinions:

It looks like that. And IMO it is totally fine. If we always were in 
agreement, we wouldn't need RFCs, Discussions and Votes and would just 
commit to master :-) As I mentioned in the “Intent to Vote” email, we 
nevertheless found this discussion very valuable and are thankful you 
took the time to engage.

Best regards
Tim Düsterhus