Re: Examples comparing Block Scoped RAII and Context Managers

Hi On 12/18/25 00:04, Rowan Tommins [IMSoP] wrote:

5) Wait, does that mean this is just a sequence of declaration statements in disguise?

Yes.

    let ($foo, $bar) { … }

is equivalent to

    let ($foo) {
        let($bar) { … }
    }

And by extension

    let ($scoped, $scoped) { … }

is equivalent to

    let ($scoped) {
        let ($scoped) { … }
    }

In the example the outer $scoped will then effectively be shadowed by the inner $scoped, preventing it from being overwritten inside the block. The initializer behaves like regular assignments that PHP users are already familiar with, just with the extra feature that the old value will be backed up and then restored after the associated statement (list) finishes. The (effective) desugaring is showcased in the Proposal section of the RFC and the first example in the “Examples” section also showcase all possible situations. I have just updated the RFC to write this out more explicitly: https://wiki.php.net/rfc/optin_block_scoping?do=diff&rev2%5B0%5D=1765892090&rev2%5B1%5D=1766015568&difftype=sidebyside

If you can do that, presumably you can do this: let(

      $foo = bar($baz), // What is $baz referring to? Particularly if it is a by-reference out parameter.
      $baz = 1,

) Which is a direct translation of an example you gave here: <https://externals.io/message/129059#129583>

The $baz in bar($baz) is referring to whatever value $baz has at that point in time.

Thinking about it, even the dynamic coding features of PHP you say would be so difficult aren't automatically prohibited:

I assume you are referring to this email here: https://news-web.php.net/php.internals/129641? I was specifically mentioning the dynamic coding features as problematic in combination with a possible “temporal dead zone”. Since the let() construct requires all variables to be declared at the start of the block in a dedicated section there is no (or less) issue of there being multiple equally-valid interpretations for the behavior of variables that are declared “halfway through” a block: 1. The “temporal dead zone” is not something that can exist. 2. And users do not need to wonder if declarations are hoisted. For the example in the email you linked, I am including it here once more (with an additional $baz = 2 assignment at the start):

    $baz = 2;
    {
         let $foo = bar($baz);

         let $baz = 1;
     }

1. If there is a temporal dead zone, the call bar($baz) is invalid (throws an Error). 2. If declarations are hoisted, the call to bar($baz) could be (1) an access to an undefined variable (if it behaves as if there was an unset($baz), which would be behavior that is technically different from the TDZ). It could also be a valid access to a variable containing null (if all variables are initialized to null). *Theoretically* it could also be 1, if only constant expressions are legal and the initializer is also hoisted. 3. If the lifetime of the block-scoped $baz only starts at the point of declaration - effectively an invisible nested block - it behaves as if it was bar(2), since the current value of $baz is 2. To me the syntax of the let() construct very strongly suggests (3) and when there is only one variable declared (or one knows the desugaring of let($foo, bar) == let($foo) let($bar)) there is no other possible interpretation. This is what I meant by “there is a less rigid relationship between the individual statements” in the previous email. Note that it also said “Forcing all the declarations into a single statement would resolve that ambiguity […]”, since that would be isomorphic to the let() construct if the declaration is forced to be at the top of the block. Best regards Tim Düsterhus