Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117907
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <487c86cf-60c0-438f-b630-e698ee1540f2@www.fastmail.com>
In-Reply-To: 
 <CADK1yXJCQiDOZbTxpv8DLycA3wZkYPEP_bOGVH0BCRxWZgX92w@mail.gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
 <CADK1yXJCQiDOZbTxpv8DLycA3wZkYPEP_bOGVH0BCRxWZgX92w@mail.gmail.com>
Date: Sat, 11 Jun 2022 20:53:30 -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 Sat, Jun 11, 2022, at 5:01 PM, Deleu wrote:
> On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
>> On 09/06/2022 17:34, 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 ... Arnaud Le Blanc has now picked up the flag with an
>> improved implementation ... The RFC has therefore been overhauled
>> accordingly and is now ready for consideration.
>> >
>> > https://wiki.php.net/rfc/auto-capture-closure
>>
>>
>> They may sound like the same thing, but to me "short closure syntax"
>> (and a lot of the current RFC) implies that the new syntax is better for
>> nearly all closures, and that once it is introduced, the old syntax
>> would only really be there for compatibility - similar to how the []
>> syntax replaces array() and list(). If that is the aim, it's not enough
>> to assert that "the majority" of closures are very short; the syntax
>> should stand up even when used for, say, a middleware handler in a
>> micro-framework. As such, I think we need additional features to opt
>> back out of capturing, and explicitly mark function- or block-scoped
>> variables.
>>
>
> The RFC does mention that the existing Anonymous Function Syntax remains
> untouched and will not be deprecated. Whether the new syntax is better for
> nearly all closures will be a personal choice. If the new syntax doesn't
> suit, say, a middleware handler, then we still can:
> - reach for the old syntax
> - use invocable classes
> - call another method or function which creates a brand new scope and then
> returns a function/callable.

Correct.  If this RFC passes, there will be three equally supported syntaxes for creating closures:

function ($a) use ($b) {
  return $a * $b;
};

fn ($a) => $a * $b;

fn ($a) {
  return $a * $b;
};

Which one is appropriate in a given situation is left up to developer judgement.

My own personal position would be 

* use fn => where possible
* use fn {} if going mult-line.
* if the body of the closure is more than ~3 lines and is not virtually the entire wrapping scope, it should be its own named function/method *anyway*, and the new first-class-callable syntax makes that nice and easy to use.

That is, I would probably not use the manual-capture syntax very often at all.  However, if someone disagrees with me on case 3 it's still there for them if that's easier in context.

Whether the new syntax is viewed as "adding auto-capture to long closures" or "adding multi-line support to short closures" is, in the end, a mostly academic distinction with no practical difference.  The resulting syntax is smack in the middle of the two existing ones.  The original RFC from a year ago approached it from the perspective of the first;  The rewritten RFC leans on the second perspective.  The use of both names is mostly a historical artifact of reusing the old URL. :-)  The net result is the same.

--Larry Garfield