On Fri, Jul 3, 2020 at 4:35 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Mon, Jun 29, 2020 at 5:13 PM Nikita Popov <nikita....@gmail.com> wrote: > >> On Tue, Jun 23, 2020 at 12:10 PM Nikita Popov <nikita....@gmail.com> >> wrote: >> >>> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita....@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. > Okay, I think I've now done the last set of updates to this RFC: * call_user_func(), call_user_func_array(), ReflectionClass::newInstance(), ..., now support named parameters. * I've moved the alternative LSP behavior into the alternatives section and don't plan to pursue it in this RFC. After thinking it over, I think this is a nice migration hack, but not something that should be part of the language long term. Regards, Nikita
