Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130977
Date: Wed, 20 May 2026 21:01:51 +0000
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [RFC] Scope functions
Message-ID: <fba7c199-26c5-4445-8c7f-aa33b8662dde@mountainofcode.co.uk>
Feedback-ID: 198683275:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: php@mountainofcode.co.uk (MCode)

On Thu, 07 May 2026 15:19:01 +0000, Alex Rock wrote:
 > Thanks for this RFC, here are my 2cents:
 >
 > I think the current syntax is too close to current short closures, and
 > since it allows multiline closures, it would imply that by default all
 > multiline short closures are scoped, which is not intuitive since
 > traditional closures don't capture by default.
 > Instead, I think replacing the `fn () { }`=C2=A0 syntax to add a keyboar=
d
 > indicating it inherits the scope would drastically help making it more
 > intuitive.
 >
 > I would imagine instead something like this:
 >
 > =C2=A0 =C2=A0 $externalVar =3D 0;
 > =C2=A0 =C2=A0 $closure1 =3D scoped fn () =3D> $newVar1 =3D $externalVar+=
+;
 > =C2=A0 =C2=A0 $closure2 =3D scoped function () {
 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 return $newVar2 =3D $externalVar++;
 > =C2=A0 =C2=A0 };
 > =C2=A0 =C2=A0 $closure1();
 > =C2=A0 =C2=A0 $closure2();
 > =C2=A0 =C2=A0 var_dump($newVar1); // int(0)
 > =C2=A0 =C2=A0 var_dump($newVar2); // int(1)
 > =C2=A0 =C2=A0 var_dump($externalVar); // int(2)
 >
 > This way, for the first case, the only new information that `scoped`
 > brings is the potential existence of `$newVar1` after the closure's
 > execution, and for the second closure, it makes it explicit that all
 > variables in the closure's body are shared with the parent scope.
 >
 > WDYT?
 >
 > Le 06/05/2026 =C3=A0 22:09, Bob Weinand a =C3=A9crit=C2=A0:
 > > Volker and I drafted a RFC:
 > >
 > > https://wiki.php.net/rfc/scope-functions
 > >
 > > Please consider it and share your feedback.
 > >
 > > I hope it will alleviate pain around some of the most common forms of
 > > Closure usage which is "execute this now as part of the called
 > > function", which currently can require a lot of "use ($variables)".
 > >
 > > For me the primary use case of use ($capturing) was always "I need
 > > this function later and want to explicitly document what escapes my
 > > function". This, however, required this straightforward usage of
 > > Closures to also document every single usage of a variable. Which is
 > > really not that beneficial at all.
 > >
 > > Thus the scope functions as proposed will be able to fill that gap in
 > > future.
 > >
 > > Thank you,
 > > Bob

I agree that the new syntax is too close to current short closures.

I don't think we need a new keyword though, I think the presence of `=3D>`=
=20
in the function definition should indicate that scope is captured, like=20
this:

```
function() =3D> {
 =C2=A0 =C2=A0 // ...
}
```

To put it another way `fn() =3D> foo;` would be a syntactically identical=
=20
version of `function() =3D> {return foo;}`