A PHP syntax for discardable assignments

Recently, John Bafford revived a years-long conversation on expanding the syntax of the PHP foreach statement to include iterating solely over keys. Bafford, who wrote a patch and request for comments (RFC) on the matter back in 2016, hopes to update his work and convince the community to adopt the abbreviated syntax in PHP 8.1. The community took Bafford's general idea and expanded it into other areas of the language.

The PHP foreach statement is designed to iterate over arrays and objects that implement the Traversable interface. PHP arrays are analogous to Python dictionaries. Two varieties of syntax are currently available to foreach: the first extracts the value of each item, while the second extracts both the key and the value:

    $traversable = [
        'A' => 1,
        'B' => 2
    ];

    foreach($traversable as $value) { /* ... */ }

    foreach($traversable as $key => $value) { /* ... */ }

The purpose of Bafford's proposal is to provide an efficient way for the foreach statement to extract only the keys while ignoring the values; he decided on using the void keyword to indicate that the value portion should be discarded:

    foreach($traversable as $key => void) { /* ... */ }

It's not the first time this idea has been suggested; Chris London had a similar proposal back in 2013. At the time, London's suggestion didn't gain much traction, and contributor Nikita Popov characterized the use case for the syntax as "not particularly common." Moreover, as Popov wrote, PHP already provides multiple different ways of addressing this need without adding syntax to the language. One solution is to provide a variable for the value in foreach statements and not use it when only the keys are needed:

    foreach($array as $key => $_) { /* ... */ }

Note that, in the above, $_ is just a variable to PHP without any special meaning; developers, by convention, sometimes use it to signify an "unused" value. Another alternative that was suggested by Popov is to use the array_keys() function to similar effect. Using this approach, a second, integer-indexed array is created from the original array that contains the keys to iterate over, eliminating the need for an unused variable:

    foreach(array_keys($array) as $key) { /* ... */ }

The arguments against the new syntax have not changed significantly from seven years ago; Popov effectively repeated them in response to Bafford's proposal. In his opinion, it added unnecessary complexity to the language, would make foreach "marginally slower," and there are multiple valid alternatives already available to address the problem the RFC looks to solve. Not everyone in the community felt that Popov's alternatives were ideal, however. Dik Takken noted that the first option creates an unused variable, adding that "code inspection currently complains about that, and for good reason, which is annoying." As for using array_keys(), Markus Fischer wrote that this solution isn't ideal, either; the array_keys() function needs to create a new array, which could be a performance issue.

Some felt that Bafford's choice to use void wasn't the best option. Olle Härstedt suggested that the underscore character might be a better alternative to void:

foreach($iterable as $key => _) { ... }

As justification, Härstedt noted that OCaml uses the underscore symbol when the value of an assignment can be discarded. Unfortunately, _() is also an alias to the gettext() function, making it a poor choice for this purpose. Several participants in the thread preferred the keyword null to void, although Bafford was opposed to that suggestion. He argued that, because null is a value in PHP whereas void is a type, void is the better choice. With the RFC still under discussion, what keyword might ultimately be used is undecided.

Disagreements on the specific keyword aside, Takken suggested that the scope of Bafford's proposal was too narrow, writing:

There are at least two areas where this syntax would be beneficial to the language. The first is captured in Bafford's RFC, and the second is when assigning variables from an array as shown in the example below:

    [, , $a] = ['val1', 'val2', 'val3'];

To many programmers, the code above might look more like a syntax error than a valid expression. It is, however, valid PHP code, which assigns "val3" to $a; the seemingly out-of-place commas in the example above indicate that $a should be assigned the third value in the source. Härstedt noted that "anything would be better" than the current comma-only syntax; generalizing Bafford's proposal to include this aspect of PHP certainly clarifies what is happening in such an assignment operation:

    [void, void, $a] = ['val1', 'val2', 'val3'];

Takken's suggestion to generalize the syntax was positively received by Härstedt and others, including PHP 8.0 release manager Sara Golemon, who described both the proposed changes to foreach and the suggested improvements to array-value assignments "great, expressive syntaxes."

Bafford believes his proposal shouldn't hurt performance. In fact, while he was clear that "any performance benefits are secondary" to the syntactical benefits, he did make a case arguing that his proposal would benefit the run-time performance of foreach:

While Bafford may be correct that there is a theoretical performance gain, he offered no benchmarks to demonstrate that and it is unlikely to be of much practical value. Longtime project member Stanislav Malyshev explained what he felt was faulty in Bafford's analysis. In Malyshev's opinion, eliminating an opcode to retrieve the value wouldn't move the performance needle in a meaningful way:

As things stand now, Bafford's RFC needs to be updated to capture the substance of the thread and address any outstanding issues raised in it. One of the key issues is whether Bafford will broaden his RFC to a more generalized syntax, or whether he will keep it limited to his original scope. The wider scope appears to have fairly broad support in the community, so it seems likely the RFC will be updated to reflect that. In an email linked above, Bafford summed up where things stand; he also let the community know he would be taking a break from computers "for a few weeks." Since this is all planned for PHP 8.1, there isn't any rush; PHP 8.0 isn't scheduled to be released until November 26.