Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110836
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com> <CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com>
In-Reply-To: <CAF+90c8jwAk4RnGCVMC=e-L_OnvYYjnK69gUiKgGEMe26WDZdA@mail.gmail.com>
Date: Fri, 3 Jul 2020 16:35:38 +0200
Message-ID: <CAF+90c-=t2Wxr9f9dG-BSRw3=nWJPh4neT2LM05anf67-M-75Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000042d55305a98a716f"
Subject: Re: [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000042d55305a98a716f
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 29, 2020 at 5:13 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.
>

I've made two additional changes to the proposal:

1. Explicitly mentioned attribute support in
https://wiki.php.net/rfc/named_params#attributes1, and added it to the
implementation (oops). ReflectionAttribute::getArguments() will also return
named arguments to the attribute, and ReflectionAttribute::newInstance()
will behave in the intuitive manner.

2. Added some information on internal APIs in
https://wiki.php.net/rfc/named_params#internal_apis. The tl;dr is that
named params are pretty much completely transparent for normal extensions,
but there are some additional APIs if for example you want to perform a
named param call from an extension.


In relation to this, I'm also considering to change the semantics of
call_user_func_array() to treat array elements with string keys as named
parameters, rather than simply ignoring keys. The motivation here is not so
much call_user_func_array() in particular, but various other APIs that do
the same thing, such as ReflectionMethod::invokeArgs(), which should all
behave consistently.

Relatedly, I'm wondering if something like this should be allowed:

    call_user_func('strlen', str: 'foo');

I'm leaning towards "yes", in which case call_user_func_array() should be
also be treated consistently.

Regards,
Nikita

--00000000000042d55305a98a716f--