[RFC] Spread Operator in Array Expression v0.2

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread Operator in Array Expression. 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

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ł:

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread
Operator in Array Expression. 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

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.

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

Hi!

Thanks for the people who joined the discussion of my RFC: Spread
Operator in Array
Expression. 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

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]

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread Operator in Array Expression. 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

--

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?

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

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread Operator in Array Expression. 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

--
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?

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

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]

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:

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread Operator in Array Expression. 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

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

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?

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]

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

The original argument unpacking RFC 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

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

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

Hi internals,

Thanks for the people who joined the discussion of my RFC: Spread
Operator in Array Expression. 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

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

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.

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 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.