An alternative syntax would be
foreach($iterable as $key => _) { ... }
Using underscore as a way to signal "I don't care about this value".
Same could be possible with list destructoring, like
[_, _, $something] = foo();
This syntax comes from OCaml. Possibly other languages, too? Not sure.
2020-09-02 3:15 GMT, Mike Schinkel <m...@newclarity.net>:
> 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>
>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
