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

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