Hey folks,
Currently argument unpacking can only be used once in a call and only
after all positional arguments were passed.
E.g. func(1, 2, 3, ...[4, 5]) is allowed, but func(...[1, 2, 3], 4,
...[5]) is not.
This makes it impossible to use this feature with some of the ext/std
functions (array_udiff, array_interect_ukey, etc.) and just feels a bit
incomplete...
I would like to propose to allow usage of argument unpacking at any place
in arguments you are passing.
The patch is pretty simple, you look at it here:
https://github.com/nikita2206/php-src/compare/master...unpack-mid-argument-list
I still haven't tested performance on the real life apps, but all the
synthetic benchmarks (incl. deep recursion in order to let call stack go
over the cpu cache) show that there's no difference between this patch and
master. Callgrind shows that there is a small increase in the number of
instructions ran, which is expected but seems as to be negligible. (It's
about 0.5% increase for recursion benchmark).
I'm not sure if this change requires an RFC because this is a pretty
small, advancement of already existing feature that doesn't contain any BC
breaks. So I would be happy if this could go forward without it, but if
people disagree here I will make an RFC, that's not a problem (although I
would need some karma...)
Hi Nikita,
-----Ursprüngliche Nachricht-----
Von: Niktia Nefedov [mailto:inefedor@gmail.com]
Gesendet: Freitag, 20. Februar 2015 22:43
An: internals@lists.php.net
Betreff: [PHP-DEV] Allow to use argument unpacking at any place in
arguments listHey folks,
Currently argument unpacking can only be used once in a call and only after all positional arguments were passed.
E.g. func(1, 2, 3, ...[4, 5]) is allowed, but func(...[1, 2, 3], 4,
...[5]) is not.This makes it impossible to use this feature with some of the ext/std
functions (array_udiff, array_interect_ukey, etc.) and just feels a bit incomplete...I would like to propose to allow usage of argument unpacking at any place in arguments you are passing.
The patch is pretty simple, you look at it here:
https://github.com/nikita2206/php-src/compare/master...unpack-mid-argu
ment-listI still haven't tested performance on the real life apps, but all the
synthetic benchmarks (incl. deep recursion in order to let call stack
go over the cpu cache) show that there's no difference between this
patch and master. Callgrind shows that there is a small increase in the number of instructions ran, which is expected but seems as to be negligible. (It's about 0.5% increase for recursion benchmark).I'm not sure if this change requires an RFC because this is a pretty
small, advancement of already existing feature that doesn't contain
any BC breaks. So I would be happy if this could go forward without
it, but if people disagree here I will make an RFC, that's not a
problem (although I would need some karma...)--
To unsubscribe,
visit: http://www.php.net/unsub.php
I do not know the internal processes that well but I suppose a RFC is required which needs 2/3 since this is a language change.
Personally, I do not like your proposed change because static analysers are no longer able to deal with positional arguments. As far as I remember it was proposed initially in the unpacking RFC but was changed later on.
https://wiki.php.net/rfc/argument_unpacking
Maybe Nikita can give further information about the reasons behind it.
Cheers,
Robert
Hi!
This makes it impossible to use this feature with some of the ext/std
functions (array_udiff, array_interect_ukey, etc.) and just feels a bit
incomplete...
I see how it can be useful with crazy functions like array_udiff, but
these are in tiny minority. What I am concerned about is that besides
those functions - which are weird anyway - code like foo($a, ...$b, $c)
would be completely unmanageable as it would be impossible to know where
$c is actually going. I think the case for weird array functions is
pretty narrow and can be handled in ad-hoc manner without introducing
this construct.
I'm not sure if this change requires an RFC because this is a pretty
small, advancement of already existing feature that doesn't contain any
It's a new syntax (yes, looking a lot like an old one, but still new),
so I think it requires an RFC.
Stas Malyshev
smalyshev@gmail.com