Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110780
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com>
In-Reply-To: <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com>
Date: Mon, 29 Jun 2020 17:13:43 +0200
Message-ID: <CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000020ed6805a93a824e"
Subject: Re: [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000020ed6805a93a824e
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> Hi internals,
>>
>> I've recently started a thread on resurrecting the named arguments
>> proposal (https://externals.io/message/109549), as this has come up
>> tangentially in some recent discussions around attributes and around object
>> ergonomics.
>>
>> I've now updated the old proposal on this topic, and moved it back under
>> discussion: https://wiki.php.net/rfc/named_params
>>
>> Relative to the last time I've proposed this around PHP 5.6 times, I
>> think we're technically in a much better spot now when it comes to the
>> support for internal functions, thanks to the stubs work.
>>
>> I think the recent acceptance of the attributes proposal also makes this
>> a good time to bring it up again, as phpdoc annotations have historically
>> had support for named arguments, and this will make migration to the
>> language-provided attributes smoother.
>>
>> Regards,
>> Nikita
>>
>
> As we're moving in on feature freeze, I plan to move this proposal forward
> soonishly.
>
> I have update the RFC to drop the syntax as an open question (I haven't
> seen much opposition to the use of ":"), and to describe the possible
> alternative LSP behavior at
> https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
> .
>
> While writing this down and implementing it, I found that this has more
> odd edge-cases than anticipated. Overall, I'm not sold that this approach
> is worth it. It sounds nice on paper, but I strongly suspect that it solves
> a problem that does not existing in practice, and will force us to keep
> this patch-over mechanism indefinitely, while the real solution would have
> been to fix the limited amount of code that is in the intersection of
> "renames parameters" and "is actually invoked with named arguments".
>

Just as another reminder: I plan to put this to voting by the end of the
week.

I've also updated the RFC to make the LSP behavior a secondary vote. I'm
not convinced this is a good idea myself, but some others seemed to prefer
this approach.

Regards,
Nikita

--00000000000020ed6805a93a824e--