Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117897
MIME-Version: 1.0
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <CADyq6s+G_2YyyTb-E5DFnvxTH6J=53py=HXRBs8zhT=_3ceozA@mail.gmail.com>
 <21891029.EfDdHjke4D@arnaud-t490> <CAF+90c8APp7NN4-seshvG2JZQWH-N=RgcU7NDHD0pnGPhiPOwQ@mail.gmail.com>
 <CADyq6sL45vdpfe=AiERohR_HvFV3DN4H0v9JJSjY3EvaaT4G9A@mail.gmail.com>
 <CAF+90c8iOwLt-yWVdZRdVtZdwmY0PVV1gdjRj9At9jZ1hyccpQ@mail.gmail.com> <CADyq6s+-Waj+NEMz5pp3Ww6NYAFEYFDuiaxzk3-RvV1rWGpaSA@mail.gmail.com>
In-Reply-To: <CADyq6s+-Waj+NEMz5pp3Ww6NYAFEYFDuiaxzk3-RvV1rWGpaSA@mail.gmail.com>
Date: Thu, 9 Jun 2022 21:42:18 +0200
Message-ID: <CAF+90c_Cg0KLWwwbjFbAbm7JSgSnEBTkMp7Ti00jgmTweWcWmQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Arnaud Le Blanc <arnaud.lb@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f2747205e1090526"
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f2747205e1090526
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 9, 2022 at 9:39 PM Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Nikita,
>
> On Thu, 9 Jun 2022 at 21:35, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta <ocramius@gmail.com> wrote:
>>
>>>
>>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov <nikita.ppv@gmail.com> wrote:
>>>
>>>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc <arnaud.lb@gmail.com>
>>>> wrote:
>>>>
>>>>> > Would that allow us to get rid of `static fn () {` declarations, when
>>>>> > creating one of these closures in an instance method context?
>>>>>
>>>>> It would be great to get rid of this, but ideally this would apply to
>>>>> Arrow
>>>>> Functions and Anonymous Functions as well. This could be a separate
>>>>> RFC.
>>>>>
>>>>
>>>> I've tried this in the past, and this is not possible due to implicit
>>>> $this uses. See
>>>> https://wiki.php.net/rfc/arrow_functions_v2#this_binding_and_static_arrow_functions
>>>> for a brief note on this. The tl;dr is that if your closure does "fn() =>
>>>> Foo::bar()" and Foo happens to be a parent of your current scope and bar()
>>>> a non-static method, then this performs a scoped instance call that
>>>> inherits $this. Not binding $this here would result in an Error exception,
>>>> but the compiler doesn't have any way to know that $this needs to be bound.
>>>>
>>>> Regards,
>>>> Nikita
>>>>
>>>
>>> Hey Nikita,
>>>
>>> Do you have another example? Calling instance methods statically is...
>>> well... deserving a hard crash :|
>>>
>>
>> Maybe easier to understand if you replace Foo::bar() with parent::bar()?
>> That's the most common spelling for this type of call.
>>
>> I agree that the syntax we use for this is unfortunate (because it is
>> syntactically indistinguishable from a static method call, which it is
>> *not*), but that's what we have right now, and we can hardly just stop
>> supporting it.
>>
>
> Dunno, it's a new construct, so perhaps we could do something about it.
> I'm not suggesting we change the existing `fn` or `function` declarations,
> but in this case, we're introducing a new construct, and some work already
> went in to do the eager discovery of by-val variables.
>
> Heck, variable variables already wouldn't work here, according to this RFC
> :D
>

We're not introducing a new construct. We're just extending existing fn()
functions to accept {} blocks, with exactly the same semantics as before. I
would find it highly concerning if fn() => X and fn() => { return X; } had
differences in capture semantics. Those two expressions should be strictly
identical -- the former should be desugared to the latter.

Nikita

--000000000000f2747205e1090526--