Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115208
MIME-Version: 1.0
References: <CAF+90c_iYjsDWoqPaDtavVgj2WFdpiuBmGeQZFAqokVoVZTxoA@mail.gmail.com>
 <CAF+90c_E-CD3qQXHtuLVkfn4E_bp9pbQ4_N+aVLXi3ouH1ToiQ@mail.gmail.com>
In-Reply-To: <CAF+90c_E-CD3qQXHtuLVkfn4E_bp9pbQ4_N+aVLXi3ouH1ToiQ@mail.gmail.com>
Date: Tue, 29 Jun 2021 15:25:54 +0200
Message-ID: <CAF+90c-5WTGHM3bcAJZmaZLM4AUTnHRoskfAtgbixyu5h2cv0A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009bb81305c5e78ca1"
Subject: Re: [RFC] First-class callable syntax
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000009bb81305c5e78ca1
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 29, 2021 at 10:36 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, May 20, 2021 at 2:48 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> Hi internals,
>>
>> I'd like to present an RFC for a first-class callable syntax, which is
>> intended as a simpler alternative to the partial function application (PFA)
>> proposal:
>>
>> https://wiki.php.net/rfc/first_class_callable_syntax
>>
>> See the Rationale section for details on how this relates to PFA. Over
>> the past week, we've had a lot of discussions on how exactly PFA is
>> supposed to work (most of them OTR), and while we seem to have a tentative
>> consensus on the correct model to use (which does not match the current
>> RFC), it's clear that this feature has turned out more complicated than
>> originally anticipated. Joe (who provided the implementation for the PFA
>> RFC) is also concerned about the implementation complexity that the final
>> model would require.
>>
>> At least I personally was mainly interested in PFA because it provides a
>> first-class callable syntax as a side-effect. This RFC goes back to
>> providing *just* that. The syntax is forward-compatible with a future PFA
>> proposal though.
>>
>> Regards,
>> Nikita
>>
>
> I've updated the RFC to forbid combination with the nullsafe operator, as
> well as explicitly mention strict types behavior, as these came up in the
> PFA discussion.
>
> I plan to put up this RFC for voting in the event that the PFA proposal
> does not get accepted.
>

As syntax has been the primary point of contention for this RFC, I've
considered adding a secondary vote for an alternative syntax, with the
prime contender being strlen::fn / $foo->bar::fn / Foo::bar::fn. I have
ultimately decided against this, because the ::fn syntax is not just a
minor syntax variation: It will result in materially different semantics.
While the end goal is the same, ::fn would approach it from a technically
quite different direction, by not piggy-backing on call syntax.

If this doesn't get accepted ("I like the idea but hate the syntax" is a
sensible reason to vote against), then I'd create a separate proposal for a
different syntax choice.

Regards,
Nikita

--0000000000009bb81305c5e78ca1--