Hi
Am 2025-12-12 22:54, schrieb Larry Garfield:
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.
We very strongly disagree on this. Arbitrary block scoped variables
outside of control structures have proven their value in other
programming languages and the same use cases also apply to the use in
PHP.
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.
It does make sense on a while:
let ($row) while ($row = $statement->fetch()) {
// …
}
But that would allow for the mask/unset logic for variables that have
special meaning in existing block constructs, which is generally what
you'd be interested in. I don't think there's a huge use case for
unsetting arbitrary variables in arbitrary places. It would also be
cleaner than the current pattern of if ($x = stuff() && $x < 1) {},
which always felt clunky and "leaks" $x.
If you need some thing more arbitrary and custom than cleaning up an
existing block construct, then the additional setup of a Context
Manager is fully justified, and more robust.
We have added a new example use-case “Example showing memory-efficient
batch processing” to the RFC that shows the value of stand-alone block
scoping for a case where the goal is the unsetting and freeing of memory
and not the side-effect of calling `__destruct()`. Somehow attempting to
merge the block declaration of `$scaled` into the `foreach()` probably
not going to be particularly readable. Limiting block scoping to control
structure initializers blocks some use-cases and does not provide a
meaningful (syntactical) value-add over the dedicated construct that
composes with the existing control structures.
Best regards
Tim Düsterhus
