[RFC] Argument unpacking

Hi!

Am 31.8.2013 um 01:39 schrieb Stas Malyshev smalyshev@sugarcrm.com:

Hi!

function short (...$args) {
if (count($args))
return long(...$args, "some value");
}

This is exactly the problem. Since $args has undefined number of
arguments, there's no way to determine where "some value" ends up. Which
means it's impossible to understand what's going on here. Now, if we had
named arguments, like python had, then using "some value" as a named
argument might work (and we'd need to see what to do with named
arguments in this case), but as positional argument this just doesn't
make much sense beyond some very esoteric things that nobody uses
directly, without wrapping libraries (like partially applied functions)

• at least in PHP.

That's why there is an if (count($args)) (I just forgot to add an == 7)

It should read:

function short (...$args) {
if (count($args) == 7)
return long(...$args, "some value");
}

And when you name the example with the "esoteric things", I'd like to have them
in the most readable format possible, which isn't achievable with func_get_args().

And I think you are really arguing about non-issues.
Example: Multiple uses of unpacking syntax makes sense when you call a
function with a variadic parameter:

function variadic (...$args) {
// do something
}

variadic(...$array1, ...$array2);

Again, since parameters in PHP are positional, they have meaning
depending on position. If you just wanted to pass an array, pass an
array, you don't need to use variadic syntax for that. Variadic syntax
makes sense only if positions there have meanings and you want to give
specific meanings to specific arguments in specific positions. In that
case, ...$array1, ...$array2 doesn't work since you can not have
meaningful positions. Only case where it works if you do functional
operations like partial application, where the meaning of the function
is not important but only the fact that it is a function is important.
But I don't think we need special syntax to do such things.

I mean, it looks way cleaner to use this instead of:

call_user_func_array("variadic", array_merge($array1, $array2));

And no, the order isn't always important. Example:

function variadic (...$args) {
return array_reduce($args, function ($a, $b) { return $a*$b; }, 1);
}

Yes, this is a very simple example, but just to show the idea of it.

And even when the order is important, it may be useful:

// according to implementation, arrays are expanded in insertion order here
// https://github.com/nikic/php-src/compare/variadics...splat#L11R3263
$short_default_options = [
"arg1" => 1,
"arg2" => 3,
"arg3" => 7,
];

function short (...$extra_options) {
global $short_default_options; // in classes, this would be a $this->short_options
if (count($args) <= 3)
return long(...$short_default_options, ...$extra_options);
}

function long ($arg1, $arg2, $arg3, $arg4 = 0, $arg5 = 0, $arg6 = 0) {
// do something
}

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Bob Weinand

Hi!

Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou linepogl@gmail.com:

2013/8/31 Bob Weinand bobwei9@hotmail.com
Hi!

Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou linepogl@gmail.com:

2013/8/30 Stas Malyshev smalyshev@sugarcrm.com

don't see a reason why one should explicitly disallow doing multiple
unpacks.

Because it makes very hard to understand what's going on and makes no
sense semantically.

As you can see, here two arguments are unpacked in one call.

This is very special use case to be hidden in library functions, I don't
think we need to have language syntax specially directed at that, at the
cost of making it overall more complex and hard to understand. I can see
what "add all those params at the end" syntax mean. However having
something like ($a, ...$b, $c, ...$d, $e, $f, $g, ...$h) I have no idea
what's going on at all and what is sent where.

I agree with Stas here. If an argument comes after an unpacked array, its
position is not certain until runtime. This makes life difficult for static
analysis tools, which is one of the reasons for introducing the new syntax.

The alternative is for users to use what we have now: call_user_func_array
with some array_merge, which makes it as difficult for static analysis as the
new syntax does. This really is a non-argument.

Please read carefully my argument. The alternative is to actually call the function normally with the arguments expanded in the code.

In other words, the alternative to this:
strpos( ...$array , 3 ); // which cannot be verified statically

is this:
strpos( $array[0] , $array[1] , 3 ); // which is perfectly verifiable.

The power of this proposal is found when used with optional arguments (or variadic arguments) which always come last anyway.

Lazare INEPOLOGLOU
Ingénieur Logiciel

This also isn't anything it ever would write, because it just doesn't make any sense for two or three arguments.

In my opinion you only should unpack arrays when it's at the end … AND when you can verify how many parameters will be inserted. Just shorter. Because writing:

func($array[0], $array[1], $array[2], $array[3], $array[4], $array[5], $array[6], "value");

is just ugly to write and to read.

if (count($array) == 7)
func(...$array, "value");

is much more readable, I think.

Bob Weinand