Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129639
Precedence: list
MIME-Version: 1.0
Date: Wed, 17 Dec 2025 19:03:25 +0100
To: Pierre Joye <pierre.php@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Discussion] use construct (Block Scoping)
In-Reply-To: <CAEZPtU4BZhj7Xb4Sq0kxJVE8v8i4EceqEpZnjMWA5jjp8SjGtg@mail.gmail.com>
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>
 <b73c31e5-fb10-4899-bdb7-bf4cd0c4611f@app.fastmail.com>
 <CAEZPtU4BZhj7Xb4Sq0kxJVE8v8i4EceqEpZnjMWA5jjp8SjGtg@mail.gmail.com>
Message-ID: <2831b7be21b21f4d98ef41d67a23b40a@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-12-13 04:18, schrieb Pierre Joye:
> My primary concern with the suggestions of integrating let into
> existing control structures (if (let $x=stuff(); ...), for (let $i =
> 0; ...)) is ambiguity. The same for sequence-like syntax proposed
> earlier. PHP doesn't currently have block scoping, and introducing it
> in a way that reuses or resembles existing syntax patterns will be
> difficult to distinguish from current behavior. This could create

Yes, this is a big part of the reason we've chosen the current syntax 
with its dedicated construct that also forces all block-scoped variables 
to be defined together at the start of their respective scope.

> hidden bugs that could be hard to catch. Without talking about
> changing let to "semi" reserved word. Not sure what that means tho'.
> :)

`let()` being a semi-reserved keyword means that it will become 
unavailable for use as a free-standing function, since `let($foo = 1);` 
would be ambiguous otherwise, but it will remain available as a method 
name, since the `->` makes it clear that it must be a method call.

> The 'using' syntax proposed earlier in this thread, mapping maybe the
> 'with' behavior may also provide such an unambiguous definition.

Sorry, I'm afraid I don't understand what you mean by “mapping the 
'with' behavior”.

> I am also wondering about the actual need of having a block only
> scope, and potentially for some variables only (if that's part of the
> behaviors as well). When a scope is needed but one does not want to
> define a separate function, closure and co are cheap now. But I may
> miss some obvious benefits that could benefit from such additions.

Perhaps the new “Example showing memory-efficient batch processing” 
example (added yesterday) is making a good case? The alternatives there 
would be `unset()` or a function/Closure which then come with the 
boilerplate of passing along all variables that are required for the 
scaling logic to the function scope. I find having the logic inline to 
be pretty natural in that example.

> That would be a great addition to the RFC, actual use cases and
> benefits over alternative existing ways to do it. Almost all other
> languages provide block scoping, except bash (nice friend here ;), but
> it does not mean we have to go that way. If we do, I emphasize again,
> it needs to be extremely explicit.

The “Examples” section is starting with examples that show the feature 
in isolation to make the semantics clear, but the later examples are 
intended to be representative of real-world use-cases where we would've 
liked to have block scoping in the past. Do you wish to see more 
explicit comparisons there? Perhaps you have another use case to add?

> PS: If we were back to php2/3, heh, even 4, I would propose to simply
> introduce block scoping in full, that would have been a more standard
> approach. But time flies, and we are at php 8 and it is tricky to
> introduce this at this stage :)

Yes, that is also what the RFC tried to say in the “Design Choices” 
section (and also in my replies to Rowan). We are adding block scoping 
to a language after the fact and thus different design considerations 
apply compared to a language where block scoping is an integral part of 
the language semantics.

Best regards
Tim Düsterhus