Re: [RFC][Discussion] use construct (Block Scoping)

From: Date: Sat, 13 Dec 2025 03:18:43 +0000
Subject: Re: [RFC][Discussion] use construct (Block Scoping)
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-129600@lists.php.net to get a copy of this message
Hello, On Sat, Dec 13, 2025 at 6:10 AM Larry Garfield <larry@garfieldtech.com> wrote: > The more I think on this, the more I think that the auto-unsetting behavior of a > let would be useful *only* in combination with some other existing > block, not as its own block. > > if (let $x=stuff(); $x < 1) { ... } > > for (let $i = 0; $i < 10; $i++) { ... } > > foreach (let $arr as $k =>v) { ... } (applies to both $k and $v) > > And so on. (I'm not sure if it makes sense on a while? Possibly.) Exact syntax above is > just spitballing. I remain skeptical about adding block scoping to PHP at all, but if we do pursue this, I have concerns about the approach. I have been working on some tools I need and spent quite some time on php scoping at large, and in detail, that's mainly the reason I am jumping in for a change. 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 hidden bugs that could be hard to catch. Without talking about changing let to "semi" reserved word. Not sure what that means tho'. :) The 'using' syntax proposed earlier in this thread, mapping maybe the 'with' behavior may also provide such an unambiguous definition. If we add block scoping, it needs to be extremely explicit and unambiguous. The RFC's current syntax does achieve this. Alternative syntaxes like using (potentially mapping to with behavior) might also provide that clarity, whereas let integrated into control structures may not. 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. 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. 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 :) In short, If we do proceed, explicitness must be non-negotiable :) best, -- Pierre @pierrejoye | http://www.libgd.org

« previous php.internals (#129600) next »