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 <claude.pa...@gmail.com>
Sent: Friday, April 5, 2019 4:04 PM
To: Stijn Peeters <i...@stijnpeeters.nl>
Cc: CHU Zhaowei <m...@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 <i...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
