Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 wrote: > On Monday, April 8, 2019 9:22 PM Nikita Popov > 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 > >
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Monday, April 8, 2019 9:22 PM Nikita Popov 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
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
> Le 13 avr. 2019 à 11:09, Stijn Peeters 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On 13 April 2019 10:09:20 BST, Stijn Peeters 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
"Dan Ackroyd" schreef op 6 april 2019 07:37: > On Fri, 5 Apr 2019 at 09:03, Claude Pache 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Thu, Apr 4, 2019 at 4:15 PM CHU Zhaowei 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 > 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
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Fri, 5 Apr 2019 at 09:03, Claude Pache 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 Sent: Friday, April 5, 2019 5:01 PM To: Rowan Collins Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 pt., 5 kwi 2019 o 10:50 Rowan Collins 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 Sent: Friday, April 5, 2019 4:04 PM To: Stijn Peeters Cc: CHU Zhaowei ; PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 > Le 5 avr. 2019 à 09:45, Stijn Peeters 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
pt., 5 kwi 2019 o 10:50 Rowan Collins 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
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski 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]
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
pt., 5 kwi 2019 o 08:56 CHU Zhaowei 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?
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
> Le 5 avr. 2019 à 09:45, Stijn Peeters 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
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 (m...@jhdxr.com(mailto:m...@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 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 >
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 Sent: Friday, April 5, 2019 12:40 AM To: Derick Rethans Cc: CHU Zhaowei ; PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 On Thu, 4 Apr 2019 at 17:14, Derick Rethans 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 Sent: Friday, April 5, 2019 12:40 AM To: CHU Zhaowei Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 > On 4 Apr 2019, at 21:14, CHU Zhaowei 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
> On 4 Apr 2019, at 21:14, CHU Zhaowei 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 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
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Thu, 4 Apr 2019 at 17:14, Derick Rethans 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]
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
On Thu, Apr 4, 2019 at 9:58 AM Michał Brzuchalski 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 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 > 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 > >
