[RFC] Spread Operator in Array Expression v0.2

  105072
April 4, 2019 14:14 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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
  105076
April 4, 2019 15:57 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
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]( > 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 > >
  105078
April 4, 2019 16:06 levim@php.net (Levi Morrison)
On Thu, Apr 4, 2019 at 9:58 AM Michał Brzuchalski
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
  105079
April 4, 2019 16:14 derick@php.net (Derick Rethans)
Hi!

On Thu, 4 Apr 2019, CHU Zhaowei wrote:

> Thanks for the people who joined the discussion of my [RFC: Spread=20 > Operator in Array=20 > Expression](https://wiki.php.net/rfc/spread_operator_for_array). The=20 > biggest change is I have dropped the support for string keys in v0.2=20 > as suggested by C=C3=B4me, to make the behavior of spread operator=20 > 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=20 trying to address? It looks a little like this is just adding syntax for=20 the sake of it. cheers, Derick --=20 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
  105081
April 4, 2019 16:39 rowan.collins@gmail.com (Rowan Collins)
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]
  105089
April 5, 2019 06:56 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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 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]
  105096
April 5, 2019 08:30 michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
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?
  105098
April 5, 2019 08:50 rowan.collins@gmail.com (Rowan Collins)
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]
  105101
April 5, 2019 09:00 michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
pt., 5 kwi 2019 o 10:50 Rowan Collins 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
  105103
April 5, 2019 09:09 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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 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 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
  105176
April 9, 2019 14:09 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
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
  105082
April 4, 2019 16:40 php-lists@koalephant.com (Stephen Reay)
> 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?
  105088
April 5, 2019 06:08 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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
  105094
April 5, 2019 07:45 ik@stijnpeeters.nl (Stijn Peeters)
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](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 >
  105095
April 5, 2019 08:03 claude.pache@gmail.com (Claude Pache)
> 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
  105102
April 5, 2019 09:04 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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 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
  105121
April 6, 2019 05:36 Danack@basereality.com (Dan Ackroyd)
On Fri, 5 Apr 2019 at 09:03, Claude Pache 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
  105265
April 13, 2019 09:09 ik@stijnpeeters.nl ("Stijn Peeters")
"Dan Ackroyd" <Danack@basereality.com> schreef op 6 april 2019 07:37:

> On Fri, 5 Apr 2019 at 09:03, Claude Pache 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
  105266
April 13, 2019 09:24 rowan.collins@gmail.com (Rowan Collins)
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]
  105267
April 13, 2019 14:07 claude.pache@gmail.com (Claude Pache)
> 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
  105145
April 8, 2019 13:21 nikita.ppv@gmail.com (Nikita Popov)
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
  105323
April 21, 2019 19:31 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
On Monday, April 8, 2019 9:22 PM Nikita Popov 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.
  105324
April 21, 2019 19:36 mo.mu.wss@gmail.com ("M. W. Moe")
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:

> On Monday, April 8, 2019 9:22 PM Nikita Popov 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. > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >