On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev <smalys...@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
