Re: Argument unpacking - Multiple unpacks and trailing arguments

On 23/09/2013 21:19, Nikita Popov wrote:

That's a general issue that's not really related to multiple unpacks. It could just as well happen without any unpacks at all ( f(a => 'a', a => 'b') ) or when unpacking an iterator (which is allowed to have duplicate keys).

Fair enough. However, I'm a little concerned about the other named parameters issue here. f(1, ...$args1, 2, ...$args2) would be quite straightforward with numerical arguments, but with multiple unpacks which can also unpack named parameters, I am worried things could get quite confusing. Then again, it would be perfectly possible to write awful code with array_merge etc. anyway, so I can't really object to it.

The variadics RFC does not allow defining such functions, correct. But it's a fact that our standard library already makes use of this pattern (variadic arguments first and a fixed one at the end), so it seems somewhat reasonable to support them too.

Why would it make the code clearer? Using the array_uintersect example:

     // unpack with trailing arg
     array_uintersect(...$arrays, $compare);
     // array_merge
     array_uintersect(...array_merge($arrays, array($compare)));

Maybe I'm alone here, but I find the first line clearer than the second.

Actually, I'm changing my mind here. I can see the utility here dealing with existing functions. The inconsistency with the definition is still a bit irritating, since you can call such functions easily but the definitions would be as easy since you'd have to chop up the ...$args in the definition, but all may be sacrificed in the name of backwards-compatibility. :P -- Andrea Faulds http://ajf.me/