Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111790
MIME-Version: 1.0
References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net> <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
In-Reply-To: <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
Date: Wed, 2 Sep 2020 20:21:44 +0300
Message-ID: <CANeKSiTvrp+vi8C41bX2a7a=Ypwjn3dHJei1Z-vKSaWv2PWtuw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, John Bafford <jbafford@zort.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000058b53905ae57df5a"
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
From: benas.molis.iml@gmail.com (Benas IML)

--00000000000058b53905ae57df5a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1.

I'd also like to mention that other languages don't have any kind of
syntactic sugar/special syntax for iterating over keys. That is achieved
using a function though.

This proposal to me seems a bit like the "return if/guard" RFC i. e. I see
no value in it.

On Wed, Sep 2, 2020, 8:13 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> 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 anoth=
er
> > 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 th=
e
> 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 distinguis=
h
> this case. (Or alternatively, we'd have to specialize and increase VM cod=
e
> 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 iterato=
rs
> 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 retrie=
ve
> > the values at all.
> > >
> > > In theory, this should be a general performance win any time one need=
s
> > to iterate over only the keys of an iterable, because it does not requi=
re
> > 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, whi=
ch
> > 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
> 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 limit=
ed
> > and I'm not willing to put further time into the code unless an RFC vot=
e
> > passes.
> > >
> > > Thoughts anyone?
> >
> > +1 from me.
> >
> > BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to
> > update that?
> >
> > -Mike
>

--00000000000058b53905ae57df5a--