On Mon, Sep 23, 2013 at 9:45 PM, Andrea Faulds <a...@ajf.me> wrote:
> On 23/09/2013 20:33, Nikita Popov wrote:
>
> The main open question (or at least the focus of the discussion) seems to
>> be whether to allow multiple unpacks and trailing arguments.
>>
>>
> I'm not sure I like the idea of multiple unpacks, were we to implement
> named parameters (if you did f(...(['a' => 2]), ...(['a' => 3])) you'd
> presumably have the $a argument overridden?), but I can't oppose it for
> linear arguments alone.
>
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).
> I'm not sure about trailing arguments either. I'm not sure if there's
> really a good use case for them.
>
> I notice that we do not allow either in the variadics RFC, so I think it
> would make sense to be consistent with that.
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.
> If someone really needs to do either of these, it would be a simple
> array_merge() away, and that might make the code clearer.
>
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.
I also note that Python doesn't allow either of these. I can't find why
> exactly, but I would assume there were good reasons behind it.
>
Yes, Python doesn't allow this. Ruby also didn't allow this, but removed
the restriction in MRI 1.9.1. I couldn't find any reasoning for either
(i.e. why Python disallows it and why Ruby started allowing it).
Nikita
