On Monday, April 8, 2019 9:22 PM Nikita Popov <nikita....@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

Reply via email to