Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129204
Precedence: list
MIME-Version: 1.0
Date: Wed, 12 Nov 2025 10:53: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: <84b9dc16-3eb3-4283-b015-3af29fc0e55d@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>
Message-ID: <ac6647018284df523300b427e19cf097@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 2025-11-11 23:43, schrieb Rowan Tommins [IMSoP]:
>> That's fair. I'll look into adding more explicit comparisons to the 
>> RFC together with Seifeddine. My short answer here would be that 
>> JavaScript already had explicit scoping by means of `var` and thus 
>> folks are already used to needing to declare variables. Moving to 
>> `let` is just a smaller incremental change. This is different from PHP 
>> where all variables exist implicitly, which also means that semantics 
>> from other languages need to be adapted.
> 
> 
> Technically, JavaScript variables don't have to be declared either; the 
> difference is that they are global by default, and since function-scope 
> is generally more useful, people are indeed very familiar with "var".

You are correct, my remark was too simplified. To add to that: If you 
use `"use strict";` then the implicit fallback to global variables will 
not happen and an error will be emitted instead:

     "use strict";
     function foo() {
         a = 1;
     }
     foo();

results in: "ReferenceError: a is not defined".

> PHP does have optional keywords that declare a variable with specific 
> scope, just much less frequently used: "global" and "static". Regarding 
> the discussion on shadowing vs hoisting:
> 
> - Both "global" and "static" can shadow local variables, and indeed 
> each other: https://3v4l.org/vPr2A
> - Since the shadowing lasts until the end of the function, a shadowed 
> local variable is never re-instated, and will be de-allocated if it was 
> the only reference: https://3v4l.org/VBVkX
> - Somewhat unusually, they do this as run-time statements, so you can 
> *conditionally* shadow variables: https://3v4l.org/fK9VJ
> 
> Whether these are *good* semantics to copy for a block-scoped variable, 
> I'm not sure; but they are existing PHP semantics for a very similar 
> situation.

Thank you. I just learned that `global` didn't need to be at the start 
of a function - which might perhaps be an indication that folks will 
already put the global at the top in practice, possibly because it is 
confusing otherwise. As a trivia knowledge I also learned that `global` 
supports variable variables: https://3v4l.org/oQLjP

With regard to the RFC, I've adjusted the implementation (and RFC text) 
to make the following changes:

- Neither `global`, nor `static` may be used from within the `use()` 
block.
- `static` variables defined *before* the `use()` may not be used. 
`static` variables defined *after* are okay, since there is no 
ambiguity.
- `global` variables may be used. This is consistent with `unset()` 
allowing to break the relationship with the global: 
https://3v4l.org/j2tRa. From what I understand, `global $foo;` is 
equivalent to `$foo = &$GLOBALS['foo'];`.

>>>  I'm not aware of any language that requires a specific kind of block 
>>> in order to introduce a new scope, but that doesn't mean it's a bad 
>>> idea. The approaches I am aware of are:
>> 
>> The closest comparison to “specific kind of block” might perhaps be 
>> older versions of C which require all variables to be declared - and 
>> for them to be declared at the top of the scope without any logic 
>> running in-between.
> 
> 
> The big difference is the need for an extra level of indent (or, at 
> least, an extra pair of braces, which most people will probably assume 
> needs an extra level of indent). More often than not, there is an 
> existing block you want to scope to - a particular loop, or a 
> conditional branch, etc.

Please note that the `use()` construct does not necessarily require 
braces. Thus both of the following would already work:

     use ($foo) if ($bar) {
         //
     }

and

     if ($bar) use ($foo) {
         //
     }

> I do see the advantage of forcing them to the start, though. Languages 
> in the Pascal family might be another comparison to explore - variables 
> are all declared in a separate block at the top of a function. 
> Off-hand, I'm not sure if any allow an arbitrary nested block just to 
> introduce additional variables.

We'll look into more research in that direction.

Best regards
Tim Düsterhus

PS: I'll be on vacation Thursday - Sunday, so please be prepared for 
some delay in replying :-)