Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68754
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5220DA50.9020306@sugarcrm.com>
References: <CAF+90c_Ld1BAaj2kd+hhdNkcbj6Mar2EZSYPJaSFWqmV_tb=Xw@mail.gmail.com>
	<5220CEDE.8080600@sugarcrm.com>
	<CAF+90c_d4i0XC7d76_zfE6YLgEi_J2wv-F+kdtSCySsOSSw=9g@mail.gmail.com>
	<5220DA50.9020306@sugarcrm.com>
Date: Fri, 30 Aug 2013 21:03:20 +0200
Message-ID: <CAF+90c_iZqf0Di4hH49EW4ZYG=aHQ3Z2sU6aa6KU0cs5tjd6iQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1130cec842f25104e52ee0a9
Subject: Re: [PHP-DEV] [RFC] Argument unpacking
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1130cec842f25104e52ee0a9
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > Assuming you mean call_user_func_array, yes. This is just syntax sugar
> > for call_user_func_array. Advantages of this syntax over cufa are
> > outlined here:
> >
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array
>
> The only case that I see that could make sense is $db->query($query,
> ...$params).
>

> Multiple unpackings make no sense to me, as it is impossible to know
> which argument ends up where and no corresponding syntax exists on
> function side. Also, no other language as far as I can see allows it.
>

Not sure I get what you mean. All languages with argument unpacking allow
this. It's not commonly needed, but there are uses for it and I don't see a
reason why one should explicitly disallow doing multiple unpacks.

If you want a practical example for this, consider partial application,
where you bind a number of arguments to a function.

An "old-style" definition for this (no variadics syntax, no argument
unpack) would look like this:

function bind(callable $function) {
    $boundArgs = array_slice(func_get_args(), 1);
    return function() use ($function, $boundArgs) {
        return call_user_func_array(
            $function, array_merge($boundArgs, func_get_args()
        );
    }
}

The equivalent new-style definition with variadics syntax and argument
unpacking:

function bind(callable $function, ...$boundArgs) {
    return function(...$args) use($function, $boundArgs) {
        return $function(...$boundArgs, ...$args);
    }
}

As you can see, here two arguments are unpacked in one call.


> Also, I just noticed the RFC  tries to sneak in the exception throwing
> in the syntax construct, which we agreed not to do a long time ago and
> which was never done in the engine. We shouldn't do this - if you want
> to change PHP error handling, it should be in separate RFC for this
> purpose.
>

I tried to make sure that this does not "sneak in" but is mentioned
prominently (it's half of the by-ref section). Anyway, as already mentioned
in the RFC: Exceptions are how we deal with errors relating to Traversables
in general. Yes, also in the engine. E.g. in the foreach implementation, if
get_iterator fails an exception is thrown:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_vm_def.h#4191

If staying consistent with foreach is not wanted (or this is not considered
"consistent"), I'm also okay to turn that into a fatal error or into a
warning where the argument will simply be passed without the
reference-binding instead (like what we do when you pass a function call
that returns by-value to a by-reference parameter. Though there it's
actually just an E_STRICT.)

Nikita

--001a1130cec842f25104e52ee0a9--