Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111789
MIME-Version: 1.0
References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net>
In-Reply-To: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net>
Date: Wed, 2 Sep 2020 19:13:20 +0200
Message-ID: <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: John Bafford <jbafford@zort.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000088b7e505ae57c1b6"
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000088b7e505ae57c1b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel <mike@newclarity.net> wrote:

> 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>
>

Just like the first time this was discussed, I don't think this RFC makes a
sufficient case on why we need explicit syntax for this. Just ignoring the
value is an existing pattern that works across all PHP versions:

    foreach ($iterable as $key =3D> $_) { ... }

Introducing special syntax for this has costs, both in terms of language
complexity and in terms of implementation complexity. For example,
implementing this feature will make foreach (whether or not the value is
ignored) marginally slower, because we will have to explicitly distinguish
this case. (Or alternatively, we'd have to specialize and increase VM code
size -- it's not free in any case.)

Iterating over just the keys is not a super common pattern and we already
have a reasonable way to do it (that is imho just as clear, and actually
more concise than the proposed "null" variant). The only potential
advantage to a dedicated syntax that I see is that there could be iterators
that can cheaply produce keys, but have expensive to produce values. That
seems like an edge case of an edge case though, and is a situation where
manually calling ->key() would be justifiable.

Regards,
Nikita

> On Aug 31, 2020, at 5:50 PM, John Bafford <jbafford@zort.net> wrote:
> >
> > Hi Riikka,
> >
> >> On Aug 31, 2020, at 14:13, Riikka Kalliom=C3=A4ki <
> riikka.kalliomaki@riimu.net> wrote:
> >>
> >> A common pattern that I've seen that could dearly use PHP internal
> >> optimization, if possible, would be:
> >>
> >> foreach (array_keys($array) as $key) {
> >> }
> >
> > 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:
> >
> >       foreach($iterable as $key =3D> void) { ... }
> >
> > This would iterate over the keys of the iterable, and does not retrieve
> the values at all.
> >
> > 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 t=
o
> 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.)
> >
> > 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 ou=
t
> 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.
> >
> > Thoughts anyone?
>
> +1 from me.
>
> BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to
> update that?
>
> -Mike

--00000000000088b7e505ae57c1b6--