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
