Add func_get_named_args()

[alexandre-daubois]

I'm not entirely sure this would require a RFC. That's why I'm proposing this PR first, and I'll gladly write an RFC if someone requires it.

Allows to write the following code:

<?php

function hello(string $name, int $age, ...$args): array {
  return func_get_named_args();
}

var_dump(hello('World', 30, 'extra1', 'extra2'));

Output:

array(4) {
  ["name"]=>
  string(5) "World"
  ["age"]=>
  int(30)
  [2]=>
  string(6) "extra1"
  [3]=>
  string(6) "extra2"
}

I think this would be a nice addition. With named arguments being more and more popular and the possibility to leverage arrays spreading operator, adding this function feels natural. There's no easy way to do so currently without using reflection.

They differ a bit on they behavior with spread operator and variadic argument:

function hello(string $name, int $age, ...$args): array {
  return func_get_args();
}

var_dump(hello(...[
    'age' => 30,
    'name' => 'John',
    'extra' => 'data',
]));

/*
array(2) {
  [0]=>
  string(4) "John"
  [1]=>
  int(30)
}

-> 'extra' is missing in this output
*/

function hello_named(string $name, int $age, ...$args): array {
  return func_get_named_args();
}

var_dump(hello_named(...[
    'age' => 30,
    'name' => 'John',
    'extra' => 'data',
]));

/*
array(3) {
  ["name"]=>
  string(4) "John"
  ["age"]=>
  int(30)
  ["extra"]=>
  string(4) "data"
}
*/

Adding this function instead of updating func_get_args() seems better to me, which avoids any breaking change.

[iluuu1994]

Not too much of a fan of further expanding this kind of argument handling, but just my personal opinion. The name sounds a bit ambiguous due to "named args", makes it sound like only arguments that were passed by name would be returned. Maybe func_get_args_by_name() would be less ambiguous.

[alexandre-daubois]

An additional use case is that we often use this args handling in Symfony to add new args to methods without breaking backward compatibility between minor versions.

About the naming: your proposition would also suit me fine.

[ndossche]

Slightly related to #11517 (patch also included)

[NickSdot]

I'd love to see this!

[Lukasss93]

any news about this?

[alexandre-daubois]

Still on my list but forgot about it. I'll work on it again soon 🙂

[alexandre-daubois]

After reading the issue linked by @ndossche, I think this would deserve an RFC as it seems a bit controversial. Let's add the label so I don't forget and will try to make something up when I have some bandwidth.

[alexandre-daubois]

After spending some time on this one trying to write the right RFC and justifications, I don't feel I have enough strong arguments to defend this new feature. The more I dive into it, the more it feels like a nice-to-have, which isn't enough to me to spend time arguing about it in the internal list.

If anyone feels like it, don't hesitate to take over this topic. 🙂

[Lukasss93]

Thanks for the effort, @alexandre-daubois ❤️
@ndossche, is there any chance this feature could be implemented by you or someone else? 🥹

It would be extremely useful, as it would save me a significant amount of boilerplate code.
I’ve put together a small proof of concept in this PR.
If the answer is no, I’ll accept it and remove the PoC from my repository. 🥲

[ndossche]

Thanks for the effort, @alexandre-daubois ❤️ @ndossche, is there any chance this feature could be implemented by you or someone else? 🥹

It would be extremely useful, as it would save me a significant amount of boilerplate code. I’ve put together a small proof of concept in this PR. If the answer is no, I’ll accept it and remove the PoC from my repository. 🥲

I'm still a bit more fond of the idea I proposed ~2 years ago, along with an (by now outdated) PoC implementation: #11517 (comment)
It doesn't add a new function but adds an optional $associative argument to func_get_args. Fully BC compatible. I don't know how you feel about that?

[iluuu1994]

@Lukasss93 FWIU, the problem is also not really the implementation but going through the RFC process (which anybody is free to do). See https://wiki.php.net/rfc/howto, if you're interested in doing that.

I think this implementation is also over-optimized. I don't think we need the specialized opcode.