Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110421
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <49D2921E-3A55-4F3B-BF6C-6F6AF84F0CB9@cschneid.com> <CAF+90c8jTppPSiHxNwFhU5Vf-A-rAJxqdK9HCrXEywSM4ZdNjQ@mail.gmail.com>
In-Reply-To: <CAF+90c8jTppPSiHxNwFhU5Vf-A-rAJxqdK9HCrXEywSM4ZdNjQ@mail.gmail.com>
Date: Mon, 8 Jun 2020 14:05:03 +0200
Message-ID: <CAF+90c-rgtBmBJyCYC7fFvMYJkDB3P88T4xg151Kpw9k2WkUbQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c5ea8b05a7916c7c"
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c5ea8b05a7916c7c
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 5, 2020 at 3:40 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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.
>

I've implemented the necessary groundwork for this in
https://github.com/php/php-src/commit/b03cafd19c01db57b89727ce77cc89a7d816077c,
so now I can say for sure that using keywords as parameter name will work
fine.

Nikita

--000000000000c5ea8b05a7916c7c--