Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110386
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
In-Reply-To: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
Date: Fri, 5 Jun 2020 12:45:34 +0200
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <49D2921E-3A55-4F3B-BF6C-6F6AF84F0CB9@cschneid.com>
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: cschneid@cschneid.com (Christian Schneider)

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 =3D> '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.

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.

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).

- Chris