Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:111802 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35389 invoked from network); 3 Sep 2020 08:23:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Sep 2020 08:23:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2B4211804D8 for ; Thu, 3 Sep 2020 00:28:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from 8.mo179.mail-out.ovh.net (8.mo179.mail-out.ovh.net [46.105.75.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 3 Sep 2020 00:28:14 -0700 (PDT) Received: from player699.ha.ovh.net (unknown [10.108.42.196]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 8AD30174CFF for ; Thu, 3 Sep 2020 09:28:12 +0200 (CEST) Received: from riimu.net (mail-io1-f48.google.com [209.85.166.48]) (Authenticated sender: riikka.kalliomaki@riimu.net) by player699.ha.ovh.net (Postfix) with ESMTPSA id C28F415BFA5E0 for ; Thu, 3 Sep 2020 07:28:11 +0000 (UTC) Authentication-Results:garm.ovh; auth=pass (GARM-95G001c1161b72-da10-41df-aa16-36c18d4d49b8, 1B4B01F66EE728EA1A8C596F90E293280F304D4C) smtp.auth=riikka.kalliomaki@riimu.net Received: by mail-io1-f48.google.com with SMTP id g14so1716174iom.0 for ; Thu, 03 Sep 2020 00:28:11 -0700 (PDT) X-Gm-Message-State: AOAM533qX6dCjqHNbySzrsyMYAhMaP/rhGDU2dGGAta8olMpRkYfJB/Z UACTtqTgIJMjyUyVhjxMYTetLmxVLPwrCnHXysg= X-Google-Smtp-Source: ABdhPJzO5Ahz77EKbxp41ng/fGOwfYD4friNGbp20/75disxUcdtAZ+UESUHLn/I7RcQmnrBLXP+EWxoyCoSQoujD8s= X-Received: by 2002:a6b:d811:: with SMTP id y17mr2015648iob.16.1599118090392; Thu, 03 Sep 2020 00:28:10 -0700 (PDT) MIME-Version: 1.0 References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net> In-Reply-To: Date: Thu, 3 Sep 2020 10:27:59 +0300 X-Gmail-Original-Message-ID: Message-ID: To: Nikita Popov Cc: Mike Schinkel , John Bafford , PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Ovh-Tracer-Id: 11172304776848368330 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudegtddguddvtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeggfhgjhfffkffuvfgtgfesthhqredttddtjeenucfhrhhomheptfhiihhkkhgrpgfmrghllhhiohhmmohkihcuoehrihhikhhkrgdrkhgrlhhlihhomhgrkhhisehrihhimhhurdhnvghtqeenucggtffrrghtthgvrhhnpefgvdethedujeegieduheefieeiudfgffevfeejheetteefieejieffheevjefgfeenucffohhmrghinhepphhhphdrnhgvthdpghhithhhuhgsrdgtohhmnecukfhppedtrddtrddtrddtpddvtdelrdekhedrudeiiedrgeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrieelledrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehrihhikhhkrgdrkhgrlhhlihhomhgrkhhisehrihhimhhurdhnvghtpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdrnhgvth Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values From: riikka.kalliomaki@riimu.net (=?UTF-8?Q?Riikka_Kalliom=C3=A4ki?=) > 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 reason I in my previous message suggested the engine optimization for the "foreach (array_keys($array) as $val)", is because I feel that iterating over the keys of arrays is, in my experience, a relatively common pattern. The reason is that array keys are occasionally used for storing things like strings or numbers, especially when you need a simple to implement unique list. On the other hand, I have never had the need to specifically iterate over the keys of an iterator. Additionally, I feel that there are other advantages to (at least) implementing that optimization: - The engine itself does not necessarily need to handle it differently from normal foreach. Maybe the engine could, in fact, treat it just like "foreach ($array as $val =3D> $_)" - This is a pattern that I already see happening a lot in existing code, so optimizing this case would give some benefits to existing implementation - This would not require any changes to existing php syntax - Should special syntax be introduced later, this case could be converted into that syntax at that point While the disadvantage of doing just this is that you can't easily apply it to iterators, the thing is that iterators are already calling other functions. The point here is to apply additional context awareness to avoid unnecessary execution on existing language constructs. I would see this more akin to dead code optimization than a language feature. On Wed, Sep 2, 2020 at 8:14 PM Nikita Popov wrote: > > On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel 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 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 iterator= s). > > 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 --=20 Riikka Kalliom=C3=A4ki https://github.com/Riimu