Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain tutteli.ch designates 80.74.154.78 as permitted sender)
To: "'Niktia Nefedov'" <inefedor@gmail.com>,
	<internals@lists.php.net>
References: <op.xudk90d77q1gix@nikita-hp-elitebook-750-g1>
In-Reply-To: <op.xudk90d77q1gix@nikita-hp-elitebook-750-g1>
Date: Sat, 21 Feb 2015 21:26:19 +0100
Message-ID: <006801d04e14$a6d9d2f0$f48d78d0$@tutteli.ch>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKeRv/R9dSLpwVqD590n0HcTM+RvJtfmz9A
Content-Language: de-ch
Subject: AW: [PHP-DEV] Allow to use argument unpacking at any place in arguments list
From: php@tutteli.ch ("Robert Stoll")

Hi Nikita,

> -----Urspr=C3=BCngliche 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=20
> arguments list
>=20
> Hey folks,
>=20
> 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.
>=20
> This makes it impossible to use this feature with some of the ext/std=20
> functions (array_udiff, array_interect_ukey, etc.) and just feels a =
bit incomplete...
>=20
> I would like to propose to allow usage of argument unpacking at any =
place in arguments you are passing.
>=20
> The patch is pretty simple, you look at it here:
> https://github.com/nikita2206/php-src/compare/master...unpack-mid-argu
> ment-list
>=20
> I still haven't tested performance on the real life apps, but all the=20
> synthetic benchmarks (incl. deep recursion in order to let call stack=20
> go over the cpu cache) show that there's no difference between this=20
> 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).
>=20
> I'm not sure if this change requires an RFC because this is a pretty=20
> small, advancement of already existing feature that doesn't contain=20
> any BC breaks. So I would be happy if this could go forward without=20
> it, but if people disagree here I will make an RFC, that's not a=20
> problem (although I would need some karma...)
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,=20
> 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.=20
https://wiki.php.net/rfc/argument_unpacking

Maybe Nikita can give further information about the reasons behind it.

Cheers,
Robert