rfc:list_keys

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:list_keys [2016/01/22 20:09] – cleanup ajfrfc:list_keys [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== PHP RFC: Allow specifying keys in list() ====== ====== PHP RFC: Allow specifying keys in list() ======
-  * Version: 1.1+  * Version: 1.1.1
   * Date: 2016-01-17   * Date: 2016-01-17
   * Author: Andrea Faulds, ajf@ajf.me   * Author: Andrea Faulds, ajf@ajf.me
-  * Status: Under discussion+  * Status: Implemented (PHP 7.1)
   * First Published at: http://wiki.php.net/rfc/list_keys   * First Published at: http://wiki.php.net/rfc/list_keys
  
Line 149: Line 149:
  
 Handling of implicit conversions of keys, and of accessing undefined keys, follows the same rules as for regular array indexing. Handling of implicit conversions of keys, and of accessing undefined keys, follows the same rules as for regular array indexing.
 +
 +==== Further Examples ====
 +
 +The use of explicit integer keys can be clearer than regular un-keyed <php>list()</php> in the same situations. Compare these two code snippets performing routing:
 +
 +<code php>
 +$result = $dispatcher->dispatch($httpMethod, $uri);
 +switch ($result[0]) {
 +    case \FastRoute\Dispatcher::FOUND:
 +        list(, $handler, $parts) = $result;
 +        
 +        // ...
 +}
 +</code>
 +
 +<code php>
 +$result = $dispatcher->dispatch($httpMethod, $uri);
 +switch ($result[0]) {
 +    case \FastRoute\Dispatcher::FOUND:
 +        list(1 => $handler, 2 => $parts) = $result;
 +        
 +        // ...
 +}
 +</code>
 +
 +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 (<php>$result[0]</php>) and positional (<php>list(, $handler, $parts)</php>. 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 ===== ===== Backward Incompatible Changes =====
Line 207: Line 233:
  
 ===== Future Scope ===== ===== 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 <php>list()</php> in function parameter lists, so that an "argument bag" parameter could be immediately destructured:  It would be useful to support <php>list()</php> in function parameter lists, so that an "argument bag" parameter could be immediately destructured: 
Line 252: Line 280:
 It has been suggested that at some point <php>list()</php> may be given an alternate syntax of <php>[]</php>, just as happened for <php>array()</php>. This would mean that there would be symmetry between the syntax for creating an array (<php>[1, 2, 3]</php>) and destructuring it (<php>[$a, $b, $c]</php>), 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. It has been suggested that at some point <php>list()</php> may be given an alternate syntax of <php>[]</php>, just as happened for <php>array()</php>. This would mean that there would be symmetry between the syntax for creating an array (<php>[1, 2, 3]</php>) and destructuring it (<php>[$a, $b, $c]</php>), 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.
  
-===== Proposed Voting Choices ===== +===== Vote ===== 
-The vote will be a simple Yes/No vote on whether to accept the RFC and merge the patch into PHP master.+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.
  
-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. 
 + 
 +<doodle title="Accept the Allow specifying keys in list() RFC for PHP 7.1, and merge the patch into master?" auth="ajf" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
  
-I have written a complete patch with tests, and made a pull request: https://github.com/php/php-src/pull/1730+php-src has a complete pull request including tests: https://github.com/php/php-src/pull/1730
  
-There is not yet a patch for the language specification.+There is a language specification pull request, also with tests: https://github.com/php/php-langspec/pull/152
  
 ===== Implementation ===== ===== Implementation =====
 +
 +Merged into php-src for PHP 7.1: https://github.com/php/php-src/commit/37c8bb58686b2d86f145ebe4fe39854f5951dcd7
 +
 +Merged into php-langspec for PHP 7.1: https://github.com/php/php-langspec/commit/0b1a497a6c847f6566f32057f55259f68bb9ce38
 +
 After the project is implemented, this section should contain  After the project is implemented, this section should contain 
-  - the version(s) it was merged to 
-  - a link to the git commit(s) 
   - a link to the PHP manual entry for the feature   - a link to the PHP manual entry for the feature
  
 ===== References ===== ===== References =====
  
-  * [[rfc:named_parameters|Named Parameters RFC]]+  * [[rfc:named_params|Named Parameters RFC]]
  
 ===== Rejected Features ===== ===== Rejected Features =====
Line 279: Line 315:
 ===== Changelog ===== ===== Changelog =====
  
 +  * v1.1.1 (2016-02-12) - Added further example
   * v1.1 - Resolved issue of whether to permit arbitrary expressions in keys (yes)   * v1.1 - Resolved issue of whether to permit arbitrary expressions in keys (yes)
   * v1.0 - First announced version   * v1.0 - First announced version
rfc/list_keys.1453493387.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools