Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52409A4D.3070404@ajf.me>
References: <CAF+90c-5b_OhTdYGqvGed_U0nuy3u=Uyednn7XmYEAq+j=mrUQ@mail.gmail.com>
	<52409A4D.3070404@ajf.me>
Date: Mon, 23 Sep 2013 22:19:09 +0200
Message-ID: <CAF+90c8F1A_26qo2r1tS1iP=uwULpM+XQSMNQrVHsVDkJOiC3A@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3587c9815c004e712bb92
Subject: Re: [PHP-DEV] Argument unpacking - Multiple unpacks and trailing arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c3587c9815c004e712bb92
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 23, 2013 at 9:45 PM, Andrea Faulds <ajf@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

--001a11c3587c9815c004e712bb92--