Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109555
MIME-Version: 1.0
References: <CAF+90c8MONp8Qh0E1qtegFb0QyZkqFv2OOirDzJds1LyOV4o5w@mail.gmail.com>
In-Reply-To: <CAF+90c8MONp8Qh0E1qtegFb0QyZkqFv2OOirDzJds1LyOV4o5w@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Tue, 7 Apr 2020 09:12:31 -0600
Message-ID: <CAAKU0unxjgv2hBL+Tu=tsX8VMbzSfpWGn8JX+3Q_jssG3_VQew@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Resurrecting named parameters
From: internals@lists.php.net ("Levi Morrison via internals")

On Tue, Apr 7, 2020 at 6:45 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> ## LSP checks for parameter names
>
> Parameter names currently have no particular significance in PHP, only
> their position in the signature is important. If named parameters are
> introduced (in a way that does not require opt-in at the declaration-site),
> then parameter names become significant. This means that changing a
> parameter name during inheritance constitutes an LSP violation (for
> non-constructor methods).

I would prefer to emit a low severity diagnostic if the parameter
names do not match during inheritance, specifically noting that named
parameter calls may not work as expected on such methods, rather than
emitting a diagnostic when named parameters get used.

If we decide to do it at named parameter usage as proposed, I would
want a stronger error than simply a diagnostic: the user is directly
hitting a case where we have very reasonable doubt that the code is
doing what was intended.

>
> ## Internal functions
>
> The larger problem is that internal functions don't have a well-defined
> concept of parameter default value. Parameter defaults are implicit in C
> code, and sometimes based on argument count checks. When named parameters
> are involved, one generally cannot assume that if a later (optional)
> parameter is passed, all earlier (optional) parameters are passed as well.

I know that if we can make parameter defaults in Reflection that some
people would consider that reason enough to vote yes on this proposal.
It's always annoying with Internal and User functions have
differences.

I am okay with a heavier cost to named parameters in general. It's a
new feature, and generally a _convenience_ one.

-----

I am a bit worried about variadics having named parameters in them. I
remember encountering code that assumes that `...$a` is a packed
array. Is that assumption always correct today?