The comma in the version using implicit keys could be missed when reading the code, and here we are mixing two different kinds of indexing: explicit ($result[0]) and positional (list(,$handler,$parts). In the version using explicit keys, it is harder to miss that the second and third element of the array are being used, and all three keys are expressed in the same, explicit fashion.

Backward Incompatible Changes

Proposed PHP Version(s)

This is proposed for the next minor or major PHP version, currently PHP 7.1.

RFC Impact

To SAPIs

No specific impact I am aware of.

To Existing Extensions

PHP extensions generally do not directly interact with the language syntax, so impact here is unlikely.

However, the addition of this syntax means that the content of the ZEND_AST_LIST abstract syntax tree node will now be different for arrays with keys, so this will affect extensions that deal with the AST.

To Opcache

I have not yet verified the RFC's compatibility with opcache. The ZEND_FETCH_LIST opcode can now take a string OP2, and OP2 can now be TMPVAR as well as CONST (so that constants resolved at runtime work), which might create problems if Zend Optimizer handles this opcode.

New Constants

No new constants are introduced.

php.ini Defaults

No impact on php.ini.

Resolved Issues

Should arbitrary expressions be allowed as keys?

Given this syntax, it was thought there might be potential confusion as to what $foo does:

The problem was that there were two different behaviours that might be expected here:

$foo is set to the key of the first element in $array, and $bar is set to its key $array (i.e. $bar=reset($array);$foo=key($array);)

$bar is set to the value of the element in $array with the key $foo (i.e. $bar=$array[$foo];)

So, this was initially not allowed in order to prevent misunderstanding. However, after discussions and further thought, it seemed as though misinterpreting it as doing the first thing (taking the key of the first element) was unlikely, and so we do not need to restrict arbitrary expressions. It also is more useful to accept them, since this means things like object keys (e.g. with SplObjectStorage) can work.

Open Issues

None.

Unaffected PHP Functionality

This does not impact the array() syntax or the behaviour of array indexing.

Future Scope

The following is merely potential future scope and is not part of the proposal proper, nor being voted on in this RFC.

It would be useful to support list() in function parameter lists, so that an “argument bag” parameter could be immediately destructured:

This would be more practical to implement than the Named ParametersRFC, and could be applied to existing functions which already use the “argument bag” pattern. Destructuring syntax in parameter declarations is a feature in some other programming languages, for example in ECMAScript 6. Destructuring of arrays is also a subset of what is possible with pattern matching, which is a feature of many functional programming languages.

If we implemented this, we might want to extend the syntax to support type declarations:

It was the future possibility of using list() in function parameter lists that motivated the creation of this RFC. It is not part of this RFC, however, but would be proposed in a subsequent RFC if this one passes.

It has been suggested that at some point list() may be given an alternate syntax of [], just as happened for array(). This would mean that there would be symmetry between the syntax for creating an array ([1,2,3]) and destructuring it ([$a,$b,$c]), as there is in some other programming languages. This proposal to allow specifying keys would not present any issues for this alternate syntax that I am aware of.

Vote

The vote is a simple Yes/No vote on whether to accept the RFC and merge the patch into PHP master. As this adds a feature to the language, this RFC requires a 2/3 majority to succeed.

Voting started on 2016-02-05 and ended on 2016-02-14.

Accept the Allow specifying keys in list() RFC for PHP 7.1, and merge the patch into master?