Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130794
Message-ID: <80bfec8c-821e-497b-a445-8ecf18860d41@gmail.com>
Date: Thu, 7 May 2026 17:19:01 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Scope functions
Content-Language: fr
To: internals@lists.php.net
References: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
In-Reply-To: <0187D382-80FD-432C-B0D5-B0F9D8783419@hotmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: pierstoval@gmail.com (Alex Rock)

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 () { }`  syntax to add a keyboard 
indicating it inherits the scope would drastically help making it more 
intuitive.

I would imagine instead something like this:

     $externalVar = 0;
     $closure1 = scoped fn () => $newVar1 = $externalVar++;
     $closure2 = scoped function () {
         return $newVar2 = $externalVar++;
     };
     $closure1();
     $closure2();
     var_dump($newVar1); // int(0)
     var_dump($newVar2); // int(1)
     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 à 22:09, Bob Weinand a écrit :
> 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