Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111774
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1009EBD9-A59E-423B-8FB4-C234A4AD6DB6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Message-ID: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net>
Date: Tue, 1 Sep 2020 23:15:43 -0400
Cc: PHP internals <internals@lists.php.net>
To: John Bafford <jbafford@zort.net>
Subject: Draft RFC: foreach iteration of keys without values
From: mike@newclarity.net (Mike Schinkel)


--Apple-Mail=_1009EBD9-A59E-423B-8FB4-C234A4AD6DB6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This is a new thread for John Bafford's RFC which he mentioned on =
another thread, see below:

https://wiki.php.net/rfc/foreach_void =
<https://wiki.php.net/rfc/foreach_void>=20

> On Aug 31, 2020, at 5:50 PM, John Bafford <jbafford@zort.net> wrote:
>=20
> Hi Riikka,
>=20
>> On Aug 31, 2020, at 14:13, Riikka Kalliom=C3=A4ki =
<riikka.kalliomaki@riimu.net> wrote:
>>=20
>> A common pattern that I've seen that could dearly use PHP internal
>> optimization, if possible, would be:
>>=20
>> foreach (array_keys($array) as $key) {
>> }
>=20
> I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch =
(https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I =
think) that helps with this, by allowing the following syntax:
>=20
> 	foreach($iterable as $key =3D> void) { ... }
>=20
> This would iterate over the keys of the iterable, and does not =
retrieve the values at all.
>=20
> In theory, this should be a general performance win any time one needs =
to iterate over only the keys of an iterable, because it does not =
require the use of an O(n) iteration and building of the array that =
array_keys() would, plus it works on non-array types (such as generators =
or iterators). It also is more performant than foreach($iterable as $key =
=3D> $_) {}, because it omits the opcode that instructs the engine to =
retrieve the value. (Presumably, a future direction could include using =
this request to inform generators or iterators to only return keys, and =
not values, which could further improve performance, especially if value =
generation is expensive. But that is out of scope for this RFC.)
>=20
> If this is something we'd like for PHP 8.1 and there are no major =
objections to the idea, then after 8.0 is released, I can move the RFC =
out of Draft and into Under Discussion, and presuming a vote passes, =
I'll update the patch as necessary to work against 8.0. But my time is =
limited and I'm not willing to put further time into the code unless an =
RFC vote passes.
>=20
> Thoughts anyone?

+1 from me. =20

BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to =
update that?

-Mike=

--Apple-Mail=_1009EBD9-A59E-423B-8FB4-C234A4AD6DB6--