Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111794
To: Nikita Popov <nikita.ppv@gmail.com>, Mike Schinkel <mike@newclarity.net>
Cc: John Bafford <jbafford@zort.net>, PHP internals <internals@lists.php.net>
References: <89FF9360-609A-439F-BDBE-B3B4C141E00F@newclarity.net>
 <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
Message-ID: <a74ead4b-868e-8d85-9850-72fcdebc3cd9@gmail.com>
Date: Wed, 2 Sep 2020 21:31:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c8A7oWmM45poXj2goghCa00Jz3fiU7ud-aZgVwCfgXOzQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
From: dik.takken@gmail.com (Dik Takken)

On 02-09-2020 19:13, Nikita Popov wrote:
> 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 => $_) { ... }

While this works fine, it does introduce an unused variable. Code
inspection currently complains about that, and for good reason, which is
annoying.

Even if we decide that it is not worth the trouble for foreach loops,
there are other cases where this new syntax can work well. Array
destructuring has already been mentioned.

Another case is the one where a function intentionally does not use one
of the arguments passed to it. This happens easily when using callbacks
or when implementing interfaces. A function declaration could look like
this:

  function foo($arg, void) {}

This indicates that the second parameter is intentionally left unused.

Perhaps it is a good idea to generalize the RFC to the general concept
of "using void to intentionally ignore a variable". Maybe pick just one
use case for actual implementation and extend later using followup RFCs.

Regards,
Dik Takken