[RFC] Spread Operator in Array Expression v0.2

Michał Brzuchalski

7 years ago

Hi CHU Zhaowei,

Where can I find first RFC version? Revisited RFCs AFAIK should be served
under different name.

Personally I liked key preserve behavior. Without it use of spread operator
I array expression would have minor use. But this is my personal feeling
about only.

I think I'm missing something in RFC. Usage in key preserved array
expression is not covered and the RFC doesn't describe how it would behave.

Thanks for the efforts on it

BR,

--
Michał

czw., 4 kwi 2019, 16:15 użytkownik CHU Zhaowei <me@jhdxr.com> napisał:

Levi Morrison

7 years ago

On Thu, Apr 4, 2019 at 9:58 AM Michał Brzuchalski
<michal.brzuchalski@gmail.com> wrote:

>
> Hi CHU Zhaowei,
>
> Where can I find first RFC version? Revisited RFCs AFAIK should be served
> under different name.

Look at its history. Using the same URL is fine, as long as author(s) agree.

Derick Rethans

7 years ago

Hi!

On Thu, 4 Apr 2019, CHU Zhaowei wrote:

> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array
> Expression](https://wiki.php.net/rfc/spread_operator_for_array). The
> biggest change is I have dropped the support for string keys in v0.2
> as suggested by Côme, to make the behavior of spread operator
> consistent. I have also added Q&A to explain the questions I received.

Could you add to the RFC what the exact pain point is that this is
trying to address? It looks a little like this is just adding syntax for
the sake of it.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

Rowan Collins

7 years ago

On Thu, 4 Apr 2019 at 17:14, Derick Rethans <derick@php.net> wrote:

> Could you add to the RFC what the exact pain point is that this is
> trying to address? It looks a little like this is just adding syntax for
> the sake of it.
>

Not everything is about pain, some things are just about gain. ;)

The link Levi shared about Dart included some interesting examples of where
spreads are useful, some of which you can probably imagine happening in
PHP:
https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c

It also takes us a step closer to having a short-hand for
iterator_to_array, in the shape of [...$iterator]. On its own, that's still
pretty ugly, but it's not hard to come up with cases where it would be a
lot nicer, like concatenating two iterators:

// Before
array_merge(iterator_to_array($iter1), iterator_to_array($iter2))

// Or to generalise to all iterables
array_merge( is_array($iter1) ? $iter1 : iterator_to_array($iter1),
is_array($iter2) ? $iter2 : iterator_to_array($iter2) )

// After (handles both cases)
[ ...$iter1, ...$iter2 ]

Granted, I can't point to a real-life example of that, but it shows that
this isn't just new syntax for something that's already easy.

Regards,

--
Rowan Collins
[IMSoP]

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

Thanks Rowan. IMO it's very natural to try to apply operators to similar scenario, array construction in this case, and I'm completing the missing piece of jigsaw puzzle.

Here is a MDN document for spread operator in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals and hope you find more useful examples.

TL;DR: this RFC is not making something impossible to become possible, it's making something not so easy to become easy and efficient.

-----Original Message-----
From: Rowan Collins <rowan.collins@gmail.com>
Sent: Friday, April 5, 2019 12:40 AM
To: Derick Rethans <derick@php.net>
Cc: CHU Zhaowei <me@jhdxr.com>; PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

On Thu, 4 Apr 2019 at 17:14, Derick Rethans <derick@php.net> wrote:

> Could you add to the RFC what the exact pain point is that this is
> trying to address? It looks a little like this is just adding syntax
> for the sake of it.
>

Not everything is about pain, some things are just about gain. ;)

The link Levi shared about Dart included some interesting examples of where spreads are useful, some of which you can probably imagine happening in
PHP:
https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c

It also takes us a step closer to having a short-hand for iterator_to_array, in the shape of [...$iterator]. On its own, that's still pretty ugly, but it's not hard to come up with cases where it would be a lot nicer, like concatenating two iterators:

// Before
array_merge(iterator_to_array($iter1), iterator_to_array($iter2))

// Or to generalise to all iterables
array_merge( is_array($iter1) ? $iter1 : iterator_to_array($iter1),
is_array($iter2) ? $iter2 : iterator_to_array($iter2) )

// After (handles both cases)
[ ...$iter1, ...$iter2 ]

Granted, I can't point to a real-life example of that, but it shows that this isn't just new syntax for something that's already easy.

Regards,

--
Rowan Collins
[IMSoP]

Michał Brzuchalski

7 years ago

pt., 5 kwi 2019 o 08:56 CHU Zhaowei <me@jhdxr.com> napisał(a):

> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>

The next paragraph in MDN document is spread operator for object literals
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals
Now JavaScript objects can be used like our array with keys and I simply
don't understand why we cannot preserve keys, like in JS object literals

Sample code:
JavaScript: var a = {foo: true, ...{bar: "baz"}}; // become {foo: true,
bar: "baz"}
and you can access it via a.foo or as an array dimension a['foo'] - more or
less like PHP arrays, right with key as a dimenrsion in array

Your RFC covers:
PHP: $a = [1, 2, 3, ...[4, 5, 6]]; // resulting [1, 2, 3, 4, 5, 6]

What would happen in:
a) PHP: $a = ['foo' => true, ...[4, 5, 6]]; // ??
b) PHP $a = ['foo' => true, ...['bar' => 'baz']] // error ??

Don't get me wrong I just see spread operator in function arguments a
different feature which allows working with variadic parameters,
and we're talking about the different feature here which only use the same
operator, right?

Rowan Collins

7 years ago

On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski <michal@brzuchalski.com>
wrote:

> The next paragraph in MDN document is spread operator for object literals
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals
> Now JavaScript objects can be used like our array with keys and I simply
> don't understand why we cannot preserve keys, like in JS object literals
>

The original draft discussed this, but there wasn't agreement on how
identical keys should be handled, e.g.:

$a = ['foo' => 1, ...['foo' => 2]]

Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out
that if we get named arguments, the argument spread operator will need to
work the same way as whatever is decided for arrays.

So the current approach is to get integer keys working first, using the
same behaviour as for parameters, and then revisit string keys later.

Regards,

--
Rowan Collins
[IMSoP]

Michał Brzuchalski

7 years ago

pt., 5 kwi 2019 o 10:50 Rowan Collins <rowan.collins@gmail.com> napisał(a):

>
> The original draft discussed this, but there wasn't agreement on how
> identical keys should be handled, e.g.:
>
> $a = ['foo' => 1, ...['foo' => 2]]
>
> Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out
> that if we get named arguments, the argument spread operator will need to
> work the same way as whatever is decided for arrays.
>
> So the current approach is to get integer keys working first, using the
> same behaviour as for parameters, and then revisit string keys later.
>

So we're talking about providing incomplete feature now, right?

I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where
'foo' key results in 1

But maybe this should be optional voting for that, either way, we're
delivering feature
which has very limited usage which can be confusing, cause I can
array_merge or
use + operator so why can't I use keys with spread operator if I already
have them in
my generator, iterable or array which came from for eg. json_decode or
whatever.

--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

If we didn't provide support for string keys, we can add it back later.
If we provide this feature, and later we passed named argument with a different way to handle string keys, then it will be a huge inconsistent and difficult to fix.

Thanks,
CHU Zhaowei

-----Original Message-----
From: Michał Brzuchalski <michal@brzuchalski.com>
Sent: Friday, April 5, 2019 5:01 PM
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

pt., 5 kwi 2019 o 10:50 Rowan Collins <rowan.collins@gmail.com> napisał(a):

>
> The original draft discussed this, but there wasn't agreement on how
> identical keys should be handled, e.g.:
>
> $a = ['foo' => 1, ...['foo' => 2]]
>
> Should $['foo'] be 1 or 2? Cases were made for both, and it was
> pointed out that if we get named arguments, the argument spread
> operator will need to work the same way as whatever is decided for arrays.
>
> So the current approach is to get integer keys working first, using
> the same behaviour as for parameters, and then revisit string keys later.
>

So we're talking about providing incomplete feature now, right?

I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1

But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever.

--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Côme Chilliet

7 years ago

Le vendredi 5 avril 2019, 11:00:59 CEST Michał Brzuchalski a écrit :

> So we're talking about providing incomplete feature now, right?

As I understand it, the point is to make unpacking available to arrays, to be consistent with function calls.

// This is already supported
$result = someFunction($a, $b, ...$array);
$result = new someClass($a, $b, ...$array);

// This is not
$result = array($a, $b, ...$array);

So when building an object I can unpack, but not when building an array, why?

So the feature is designed to work the same way as for function parameters, which is why string keys are not supported, because they are not supported by the "..." operator for functions.

In the end, I see that as making a feature more complete, as the "..." operator which only supported functions will now support array constructors as well.

Côme

Stephen Reay

7 years ago

> On 4 Apr 2019, at 21:14, CHU Zhaowei <me@jhdxr.com> wrote:
>
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread Operator in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The biggest change is I have dropped the support for string keys in v0.2 as suggested by Côme, to make the behavior of spread operator consistent. I have also added Q&A to explain the questions I received.
>
> Thanks & best regards,
> CHU Zhaowei
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Can you clarify what “not supported” means in reference to string keys? What will happen if an array with string keys is used? Does it error/warn, and/or are the keys ignored or skipped?

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

A recoverable error will be thrown once a string key is encountered. Thanks for raising this question, and I've updated the RFC accordingly.

-----Original Message-----
From: Stephen Reay <php-lists@koalephant.com>
Sent: Friday, April 5, 2019 12:40 AM
To: CHU Zhaowei <me@jhdxr.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> On 4 Apr 2019, at 21:14, CHU Zhaowei <me@jhdxr.com> wrote:
>
> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread Operator in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The biggest change is I have dropped the support for string keys in v0.2 as suggested by Côme, to make the behavior of spread operator consistent. I have also added Q&A to explain the questions I received.
>
> Thanks & best regards,
> CHU Zhaowei
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit: http://www.php.net/unsub.php
>

Can you clarify what “not supported” means in reference to string keys? What will happen if an array with string keys is used? Does it error/warn, and/or are the keys ignored or skipped?

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Stijn Peeters

7 years ago

Hi,

If I understand correctly it is possible in this proposal to use normal arguments after using an unpackable argument:

$arr4 = array(...$arr1, ...$arr2, 111); //valid

This is something that is not possible when using argument unpacking in function calls:

$result = someFunction(...$arr1, ...$arr2, 111); //invalid

While I personally like the more permissive variety in this RFC, I think this could be a confusing inconsistency, and for clarity's sake it would be better to keep both instances of the unpacking syntax as consistent with each other as possible.

Best,
Stijn 

Op 4 april 2019 bij 16:15:16, CHU Zhaowei (me@jhdxr.com(mailto:me@jhdxr.com)) schreef:

Claude Pache

7 years ago

> Le 5 avr. 2019 à 09:45, Stijn Peeters <ik@stijnpeeters.nl> a écrit :
>
> Hi,
>
> If I understand correctly it is possible in this proposal to use normal arguments after using an unpackable argument:
>
> 	$arr4 = array(...$arr1, ...$arr2, 111); //valid
>
> This is something that is not possible when using argument unpacking in function calls:
>
> 	$result = someFunction(...$arr1, ...$arr2, 111); //invalid
>
> While I personally like the more permissive variety in this RFC, I think this could be a confusing inconsistency, and for clarity's sake it would be better to keep both instances of the unpacking syntax as consistent with each other as possible.
>
> Best,
> Stijn
>
>

That begs the question: why is this invalid for function calls?

In fact, I am able to easily hack around the limitation:

$result = someFunction(...$arr1, ...$arr2, ...[111]); // valid

but the limitation seems just an unnecessary annoyance.

—Claude

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

The [original argument unpacking RFC](https://wiki.php.net/rfc/argument_unpacking?rev=1389442371) does allow positional arguments after unpacking, but later it's changed due to some implement issue, see https://github.com/php/php-src/commit/d3b484df8268f7ab31c4ac39734d4b68ce2e6159

I didn't see the same limit exists for arrays, so I didn't include this rule in my RFC.

Thanks,
CHU Zhaowei

-----Original Message-----
From: Claude Pache <claude.pache@gmail.com>
Sent: Friday, April 5, 2019 4:04 PM
To: Stijn Peeters <ik@stijnpeeters.nl>
Cc: CHU Zhaowei <me@jhdxr.com>; PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> Le 5 avr. 2019 à 09:45, Stijn Peeters <ik@stijnpeeters.nl> a écrit :
>
> Hi,
>
> If I understand correctly it is possible in this proposal to use normal arguments after using an unpackable argument:
>
> 	$arr4 = array(...$arr1, ...$arr2, 111); //valid
>
> This is something that is not possible when using argument unpacking in function calls:
>
> 	$result = someFunction(...$arr1, ...$arr2, 111); //invalid
>
> While I personally like the more permissive variety in this RFC, I think this could be a confusing inconsistency, and for clarity's sake it would be better to keep both instances of the unpacking syntax as consistent with each other as possible.
>
> Best,
> Stijn
>
>

That begs the question: why is this invalid for function calls?

In fact, I am able to easily hack around the limitation:

$result = someFunction(...$arr1, ...$arr2, ...[111]); // valid

but the limitation seems just an unnecessary annoyance.

—Claude

Dan Ackroyd

7 years ago

On Fri, 5 Apr 2019 at 09:03, Claude Pache <claude.pache@gmail.com> wrote:

>
> That begs the question: why is this invalid for function calls?

At least in part, because if we ever wanted to add a standard
_toArray() method, like we have __toString(), it would be quite a
massive BC break if we already made it so that PHP automatically
encased a single variable into an array, where an array was expected.

> In fact, I am able to easily hack around the limitation:
>
>     $result = someFunction(...$arr1, ...$arr2, ...[111]); // valid
>
> but the limitation seems just an unnecessary annoyance.

Typing a couple of extra characters, to avoid needing extra magic
behaviour, seems a good trade-off to me.

cheers
Dan
Ack

Stijn Peeters

7 years ago

"Dan Ackroyd" <Danack@basereality.com> schreef op 6 april 2019 07:37:

> On Fri, 5 Apr 2019 at 09:03, Claude Pache <claude.pache@gmail.com> wrote:
> 
>> That begs the question: why is this invalid for function calls?
> 
> At least in part, because if we ever wanted to add a standard
> _toArray() method, like we have __toString(), it would be quite a
> massive BC break if we already made it so that PHP automatically
> encased a single variable into an array, where an array was expected.

I don't know if I follow you here. If we're passing a normal argument after an 
unpackable argument, why would there be an expectation of it being interpreted 
as an array? I would expect the last argument to be interpreted as an array in 
the following case:

	$result = someFunction(...$arr1, ...$lastArgument);

But not in the following:

	$result = someFunction(...$arr1, $lastArgument);

In the latter case (which is invalid right now, at least in function calls), I 
don't see the need for keeping our options open for a possible future 
__toArray(), because syntax-wise, there is nothing that would imply we want to 
have it interpreted as an array.

Is anyone aware of other arguments for not allowing normal arguments after
unpackable arguments in function calls?

Best,
Stijn

> 
>> In fact, I am able to easily hack around the limitation:
>> 
>> $result = someFunction(...$arr1, ...$arr2, ...[111]); // valid
>> 
>> but the limitation seems just an unnecessary annoyance.
> 
> Typing a couple of extra characters, to avoid needing extra magic
> behaviour, seems a good trade-off to me.
> 
> cheers
> Dan
> Ack
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Rowan Collins

7 years ago

On 13 April 2019 10:09:20 BST, Stijn Peeters <ik@stijnpeeters.nl> wrote:

>Is anyone aware of other arguments for not allowing normal arguments
>after
>unpackable arguments in function calls?

CHU Zhaowei pointed to this git commit which suggests it's an implementation issue rather than a design decision: https://github.com/php/php-src/commit/d3b484df8268f7ab31c4ac39734d4b68ce2e6159

From Nikita's excellent commit message, it sounds like normal parameter passing is compiled in an optimised way that wouldn't be safe if run after a spread operator was expanded. Rather than adding a whole bunch of complexity, the edge case was just made into a documented limitation.

Regards,

--
Rowan Collins
[IMSoP]

Claude Pache

7 years ago

> Le 13 avr. 2019 à 11:09, Stijn Peeters <ik@stijnpeeters.nl> a écrit :
>
> Is anyone aware of other arguments for not allowing normal arguments after
> unpackable arguments in function calls?

I've grabbed into the archives of internals. Apart from technical issues:

The main argument against that affordance was static analysis; i.e., in `f(...$a, $b)`, it cannot be known until runtime at what position is the argument `$b`. An interesting particular case is that an unfortunate programmer might write `strpos(...$arr, $offset)`, not realising that it is not equivalent to `strpos($arr[0], $arr[1], $offset)`.

Another argument was readability, i.e. difficulty to sort out positions with and without spread when they are intermixed.

For the case of spread operator in arrays, the static analysis argument probably does not apply.

—Claude

Nikita Popov

7 years ago

On Thu, Apr 4, 2019 at 4:15 PM CHU Zhaowei <me@jhdxr.com> wrote:

> Hi internals,
>
> Thanks for the people who joined the discussion of my [RFC: Spread
> Operator in Array Expression](
> https://wiki.php.net/rfc/spread_operator_for_array). The biggest change
> is I have dropped the support for string keys in v0.2 as suggested by Côme,
> to make the behavior of spread operator consistent. I have also added Q&A
> to explain the questions I received.
>

This looks reasonable to me. My only concern would be the "by-reference
passing" section of the RFC. The current proposal states that [...$arr]
will preserve references in $arr, which is not the behavior I would expect.

Is this choice for parity with the unpacking functionality in calls? In
that case I think it is important to understand that for argument unpacking
the handling of references is decided by the called function, not what is
in the array. If the function accepts an argument by-reference, then the
corresponding element in the array will be turned into a reference
(regardless of whether it was one before). Conversely, if the function
accepts an argument by-value, then the element from the array will be
passed by-value (regardless of whether it was a reference before). A
similar concept doesn't really exist for unpacking in arrays.

Regards,
Nikita

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago

On Monday, April 8, 2019 9:22 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> This looks reasonable to me. My only concern would be the "by-reference passing" section of the RFC. The current proposal states that [...$arr] will preserve references in $arr, which is not the behavior I would expect.
>
> Is this choice for parity with the unpacking functionality in calls? In that case I think it is important to understand that for argument unpacking the handling of references is decided by the called function, not what is in the array. If the function accepts an argument by-reference, then the corresponding element in the array will be turned into a reference (regardless of whether it was one before). Conversely, if the function accepts an argument by-value, then the element from the array will be passed by-value (regardless of whether it was a reference before). A similar concept doesn't really exist for unpacking in arrays.

No. I understand it's decided by the definition of the function that whether the arguments are passed by-value or by-reference, and it's not able to be changed by the caller. So the spread operator here extracts the array, no matter it contains referenced element or not, and the conversion from by-ref to by-val or by-val to by-ref is done during passing to the callee. Back to the array definition scenario, the spread operator will also extracts the array, and it should be the array definition to decide whether conversion is needed. Since we can define array element by reference now, it doesn't make sense to change the way of storing values just because it's unpacking. In other words, the conversion of how values are stored isn't part of spread operator.

M. W. Moe

7 years ago

Hello,

"Since we can define array element by reference now, it doesn't make sense
to change the way of storing values just because it's unpacking. In other
words, the conversion of how values are stored isn't part of spread
operator."

yes it is; no matter what you "think"; banding reality/facts only exists in
blockbusters.



On Sun, Apr 21, 2019 at 12:31 PM CHU Zhaowei <me@jhdxr.com> wrote: