Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130790
Feedback-ID: id5114917:Fastmail
Date: Thu, 07 May 2026 11:52:42 +0100
To: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Scope functions
User-Agent: K-9 Mail for Android
In-Reply-To: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
References: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
Message-ID: <6B83B07A-0344-4149-BFE9-7F3DD21BBA39@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 6 May 2026 21:09:45 BST, Bob Weinand <bobwei9@hotmail=2Ecom> wrote:
>Volker and I drafted a RFC:
>
>https://wiki=2Ephp=2Enet/rfc/scope-functions


Hi Bob,=20

An I right in thinking that this is essentially equivalent to "automatic c=
apture by closure", with an extra restriction on the lifetime of the result=
ing closure? It would be good to spell out in the RFC how this compares to =
other approaches, and other languages=2E

In particular, JavaScript's capture semantics are somewhat notorious as a =
source of confusion=2E A common example is creating closures in a loop whic=
h all use the same variable; as far as I can see, the proposed semantics wo=
uld allow this as long as they were executed before the parent scope ends:


```
function parent_scope() {
    $values =3D range(1,10);

    $scoped_functions =3D [];
    foreach( $values as $v ) {
        $scoped_functions[] =3D fn($v) {
            echo "Chosen item is {$v}";
        };
    }
   =20
    run_random_callable($scoped_functions);
}

/**
 * @param callable[] $callables
 */
function run_random_callable($callables) {
    $pick =3D array_rand($callables);
    $callables[$pick]();
}

// Will always output 'Chosen item is 10'!
// The list of "scoped functions" will all actually refer to the same $v, =
updated in the loop
parent_scope();
```


I don't know if there's some way to make the lifetime even more restricted=
, so that the use cases of "immediate execution" are allowed, but this kind=
 of code is not=2E


For something like "run this in a transaction", the closure is really acti=
ng like a poor man's "continuation": it creates two new stack frames (trans=
action wrapper, callback) when what you really want is to *interleave* the =
boilerplate and the case-specific code=2E

In that sense, hygienic macros are probably the "ideal" solution - everyth=
ing is expanded inline into a single scope, and there's no Closure object w=
hich can be misused=2E

Context Managers could in fact be implemented as such a macro, and as I un=
derstand it, the implementation is basically doing that internally by manip=
ulating ASTs=2E

I wonder if there's any "minimal" macro system which would allow this kind=
 of inline boilerplate expansion, without needing to design an entire meta-=
language?


Regards,

Rowan Tommins
[IMSoP]