Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110708
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
In-Reply-To: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
Date: Tue, 23 Jun 2020 12:10:01 +0200
Message-ID: <CAF+90c_hndba0oLbL-BX9i3N-1Dhy=R2xW-hq6C0Rv2j3mKcTQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f6391705a8bd90d7"
Subject: Re: [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f6391705a8bd90d7
Content-Type: text/plain; charset="UTF-8"

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".

Regards,
Nikita

--000000000000f6391705a8bd90d7--