Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69300
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.197 as permitted sender)
Message-ID: <5240A5E2.90507@ajf.me>
Date: Mon, 23 Sep 2013 21:34:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CAF+90c-5b_OhTdYGqvGed_U0nuy3u=Uyednn7XmYEAq+j=mrUQ@mail.gmail.com>	<52409A4D.3070404@ajf.me> <CAF+90c8F1A_26qo2r1tS1iP=uwULpM+XQSMNQrVHsVDkJOiC3A@mail.gmail.com>
In-Reply-To: <CAF+90c8F1A_26qo2r1tS1iP=uwULpM+XQSMNQrVHsVDkJOiC3A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Argument unpacking - Multiple unpacks and trailing
 arguments
From: ajf@ajf.me (Andrea Faulds)

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/