Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <004a01ceb8a2$7a586830$6f093890$@tutteli.ch>
References: <CAF+90c-5b_OhTdYGqvGed_U0nuy3u=Uyednn7XmYEAq+j=mrUQ@mail.gmail.com>
	<69BCC163-7988-4EBB-A817-5F5007EC924C@strojny.net>
	<004a01ceb8a2$7a586830$6f093890$@tutteli.ch>
Date: Mon, 30 Sep 2013 14:56:58 +0200
Message-ID: <CAF+90c8J0e7JogjUk45HPy2Cc+aw9u5mTyz_LsquvwcMfkj6=g@mail.gmail.com>
To: Robert Stoll <rstoll@tutteli.ch>
Cc: Lars Strojny <lars@strojny.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b33db441f250004e7995f9b
Subject: Re: [PHP-DEV] Argument unpacking - Multiple unpacks and trailing arguments
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b33db441f250004e7995f9b
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 23, 2013 at 11:18 PM, Robert Stoll <rstoll@tutteli.ch> wrote:

> Personally I would allow multiple unpacking but not allow unpacking for
> non-variadic parameters thus:
>
> function foo(...$arr){}  foo(...$arr, ...$arr2); //is fine
> function foo(...$arr){}  foo(1, 2, ...$arr, ...$arr2); //is fine
> function foo($foo, $bar, ...$arr){} foo(1,2,...$arr, ...$arr2); //is fine
> as
> well
> function foo($foo, $bar, ...$arr){} foo(1, ...$arr, ...$arr2, 2);
> //shouldn't be allowed IMO - ...$arr is not passed to a variadic parameter
>

Introducing such a restriction doesn't make sense. A large number of uses
(you might even say "most of the uses") of call_user_func_array is in call
forwarding. In such cases the target function is usually not variadic. Also
don't forget that PHP always supported variadics via func_get_args() and
I'd like to continue supporting that style as well. Anything that tries to
match up the unpack with a variadic arguments drop the utility of this
feature to about zero.


> I think the readability is harmed when the user is not able to tell
> directly
> which arguments are passed to which parameters. For instance:
> function foo($foo, $bar){}
> function bar($foo, $bar, ...$arg){}
>
> function doIt(Iterator $iterator){
>     foo(...$iterator);
>     bar(...$iterator);
> }
>
> Depending on the implementation of $iterator the value passed to the
> parameters $foo and $bar will be different (regardless of the ...$arg in
> function bar) and you will have a hard time to understand the code quickly.
>

Sorry, I don't understand what you're saying here. Unless your $iterator is
some weird "output random stuff"-iterator, I don't see why the arguments to
$foo and $bar would be different. If $iterator is a one-time iterator, the
second call will simply fail (just like any time when you use a one-time
iterator twice...)

Nikita

--047d7b33db441f250004e7995f9b--