Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118123
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-ID: <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com>
In-Reply-To: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
Date: Wed, 29 Jun 2022 12:30:11 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:
> Last year, Nuno Maduro and I put together an RFC for combining the 
> multi-line capabilities of long-closures with the auto-capture 
> compactness of short-closures.  That RFC didn't fully go to completion 
> due to concerns over the performance impact, which Nuno and I didn't 
> have bandwidth to resolve.
>
> Arnaud Le Blanc has now picked up the flag with an improved 
> implementation that includes benchmarks showing an effectively net-zero 
> performance impact, aka, good news as it avoids over-capturing.
>
> The RFC has therefore been overhauled accordingly and is now ready for 
> consideration.
>
> https://wiki.php.net/rfc/auto-capture-closure

The conversation has died down, so we'll be opening the vote for this tomorrow.

Two changes of note since the discussion started:

* The option to mix explicit capture and implicit capture has been removed as too confusing/unpredictable.  Either trust the engine to capture the right things (the new syntax proposed here) or explicitly list everything (the existing syntax we've had since 5.3.)
* We added a section discussing the `use(*)` syntax alternative, and why it wasn't, er, used.  (Pun only sort of intended.)

--Larry Garfield