Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117892
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <894eae13-a26b-4f30-be26-1859a308e0f8@www.fastmail.com>
In-Reply-To: 
 <CABdc3WrGPEGi_iS0=QbL3H5LxEJ-SSFKwHzrcyLk6kWA2tF9uQ@mail.gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <CABdc3WrGPEGi_iS0=QbL3H5LxEJ-SSFKwHzrcyLk6kWA2tF9uQ@mail.gmail.com>
Date: Thu, 09 Jun 2022 14:19:05 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 1:36 PM, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Larry,
>
> czw., 9 cze 2022 o 18:34 Larry Garfield <larry@garfieldtech.com> napis=
a=C5=82(a):
>
>> Last year, Nuno Maduro and I put together an RFC for combining the
>> multi-line capabilities of long-closures with the auto-capture compac=
tness
>> of short-closures.  That RFC didn't fully go to completion due to con=
cerns
>> 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 implement=
ation
>> 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
>
>
> Nice work. Well-described behaviors.
>
> One question, more around future scope or related functionality in the
> future:
> A future RFC for "short-methods" described here in one of your decline=
d RFC
> https://wiki.php.net/rfc/short-functions in the past could be revived =
with
> no conflicts in the scope of methods?
>
> class Foo {
>     public string $firstName =3D 'John';
>     public function getFirstName(): string =3D> $this->firstName;
> }
>
> I'm asking if I understand the scopes of this and previous RFCs correc=
tly
> and if they don't block in future "short-methods"?
>
> Cheers,
> Micha=C5=82 Marcin Brzuchalski

The short-functions RFC is entirely separate.  The syntax choices in bot=
h that RFC and this one were made to ensure that they don't conflict wit=
h each other, and the resulting syntax meaning is consistent across the =
language.  The implementations are independent and should in no way conf=
lict.

(The short-functions RFC would have enabled short-methods too.  It was p=
urely a syntax sugar with no additional behavior.)

That's assuming the attitude toward the short-function RFC ever changes =
enough in the future to make it worth trying again...

--Larry Garfield