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

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