Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.
https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments must
be sorted after positional argument.
Are there any concerns with relaxing this restriction?
Regards,
Nikita
Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments must
be sorted after positional argument.Are there any concerns with relaxing this restriction?
Regards,
Nikita
How do named parameters interact with the variadic parameter?
function f(...$params) { var_dump($params); }
$args = [1, 2, 3];
f(...$args, params: [4, 5, 6]);
On Tue, May 25, 2021 at 4:36 PM Levi Morrison levi.morrison@datadoghq.com
wrote:
Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments
must
be sorted after positional argument.Are there any concerns with relaxing this restriction?
Regards,
NikitaHow do named parameters interact with the variadic parameter?
function f(...$params) { var_dump($params); } $args = [1, 2, 3]; f(...$args, params: [4, 5, 6]);
Ah, I think I should have mentioned that the proposed change doesn't
actually allow you to do anything new or different -- it only removes an
arbitrary syntactical limitation. In particular
func(...$args, x: $y)
will behave the same as
func(...[...$args, 'x' => $y]);
with the only difference that if $args already contained an 'x' key, that
would be an error, instead of silently ignored.
So to answer your question: Variadic parameters are not targetable by named
parameters, so what you wrote will pass [1, 2, 3, 'params' => [4, 5, 6]] as
usual.
Regards,
Nikita
Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments must
be sorted after positional argument.Are there any concerns with relaxing this restriction?
Any further feedback on this?
Nikita
Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments must
be sorted after positional argument.Are there any concerns with relaxing this restriction?
Any further feedback on this?
Nikita
I guess no one has concerns. I'm fine with it.
--Larry Garfield
Hi internals,
Currently, argument unpacking (...$foo) cannot be combined with named
arguments (foo: $bar) at all. Both func(...$args, x: $y) and func(x: $y,
...$args) are rejected by the compiler.https://github.com/php/php-src/pull/7009 relaxes this by allowing
func(...$args, x: $y). The named arguments are required to come last,
because this automatically enforces the invariant that named arguments must
be sorted after positional argument.Are there any concerns with relaxing this restriction?
Any further feedback on this?
Nikita
No objection. In my head I figured the unpack would come after named
parameters, but it makes sense that an unpack which can contain both
positional and named arguments would come between the positional and
named arguments.