"Dan Ackroyd" <dan...@basereality.com> schreef op 6 april 2019 07:37:
> On Fri, 5 Apr 2019 at 09:03, Claude Pache <claude.pa...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
