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. Regards, Nikita
