> 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 => $_)" - 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 <nikita....@gmail.com> wrote: > > On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel <m...@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 => $_) { ... } > > 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 <jbaff...@zort.net> wrote: > > > > > > Hi Riikka, > > > > > >> On Aug 31, 2020, at 14:13, Riikka Kalliomäki < > > riikka.kalliom...@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 => 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 => $_) {}, > > 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.) > > > > > > 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. > > > > > > Thoughts anyone? > > > > +1 from me. > > > > BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to > > update that? > > > > -Mike -- Riikka Kalliomäki https://github.com/Riimu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
