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.
From: Claude Pache firstname.lastname@example.org>
Sent: Friday, April 5, 2019 4:04 PM
To: Stijn Peeters <email@example.com>
Cc: CHU Zhaowei <firstname.lastname@example.org>; PHP internals <email@example.com>
Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
> Le 5 avr. 2019 Ã 09:45, Stijn Peeters <firstname.lastname@example.org> a Ã©crit :
> 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.
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, ...); // valid
but the limitation seems just an unnecessary annoyance.