Re: [RFC] Named arguments

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