Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

This is only part of a thread. view whole thread
  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 > >