Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110387
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <49D2921E-3A55-4F3B-BF6C-6F6AF84F0CB9@cschneid.com>
In-Reply-To: <49D2921E-3A55-4F3B-BF6C-6F6AF84F0CB9@cschneid.com>
Date: Fri, 5 Jun 2020 15:40:22 +0200
Message-ID: <CAF+90c8jTppPSiHxNwFhU5Vf-A-rAJxqdK9HCrXEywSM4ZdNjQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000160eef05a7566806"
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000160eef05a7566806
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider <cschneid@cschneid.com>
wrote:

> Am 05.05.2020 um 15:51 schrieb Nikita Popov <nikita.ppv@gmail.com>:
> > \I've now updated the old proposal on this topic, and moved it back under
> > discussion: https://wiki.php.net/rfc/named_params
>
> First of all I really like this approach to Named Parameters: It seems to
> fit well with the rest of PHP.
>
> Note: I'm using the key: 'value' syntax instead of key => 'value' here but
> that's just because I prefer that syntax and think it more naturally
> extends to stuff like the shorthand syntax under "Future Scope" but that's
> not a prerequisite.
>
> I have two questions regarding to the Named Parameters which are not
> related to the LSP discussion.
> They might be restrictions of the current implementation mentioned in the
> RFC as opposed to design restrictions:
>
> 1) Could keywords be allowed as parameter names? Currently using class:
> 'foo' throws a syntax error.
> 2) Could positional parameters be allowed after named parameters for
> variadic functions?
>
> These two restrictions can be looked at separately and the only reason I'm
> bringing them up together is because the use case I'm looking at is HTML
> generation with something like a function div() being used as follows.
> Please don't discard the two questions just because you don't like this
> particular use-case, thank you ;-)
>         div(class: 'error',
>                 div(class: 'title', "Error Title"),
>                 "Detailed error description...",
>         )
>
> The first issue is probably mainly a parsing issue and changing T_STRING
> to identifier seems to fix it though I'm not 100% sure if there are any
> drawbacks to this.
>

Right. It should be possible to use keywords. It's a bit harder than just
replacing T_STRING with identifier, but I don't see any fundamental reason
why it shouldn't work.


> What is the main argument for not allowing positional arguments after
> named parameters for variadic functions?
> Ambiguities could still be reported if I am not mistaken.
> A work-around for the second issue would be to require an artificial
> parameter name like content taking a string or array and then do
>         div(
>                 class: 'error',
>                 content: [
>                         div(class: 'title', content: "Error Title"),
>                         "Detailed error description...",
>                 ],
>         )
> but that's somewhat more verbose without any real benefit I can see.
>

If we ignore the philosophical question of whether having positional
parameters after named is a good idea, this mostly comes down to technical
complexity. Enforcing the "named after positional" restriction is a simple
compile-time check. Without it, we would have to duplicate a large number
of argument sending instructions just for this special case. This is
basically the same reason why we don't support "foo(...$args, 1)". That's
perfectly legitimate code, but supporting it seems like more technical
complexity than it's worth.


> PS: Concerning "Future Scope: Shorthand syntax for matching parameter and
> variable name" I think allowing :$name is reasonable and thinking further
> along that line maybe variadic functions separating named from positional
> arguments could be done using func(...$positional, ...:$named) similar to
> Python's *args, **kwargs).
>

Separating positional & named variadics / unpacks in that way is certainly
a possibility, but I don't think it's the best choice for PHP. In Python
this is pretty much required, because Python has distinct list and
dictionary types. In PHP these are combined in one data structure, which
also allows us to combine them for the purpose of variadics. Combining them
makes sure that existing code using variadic forwarding will "just work"
with named parameters -- but of course, it also means that some code will
accept named parameters even though it was not explicitly designed with
that in mind. There's a trade-off there.

Regards,
Nikita

--000000000000160eef05a7566806--