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/19 18:04] – fix formatting 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 75: Line 75:
 </code> </code>
  
-Keys can not only be literals like <php>2</php> or <php>"foo"</php>, but also constants:+Keys can not only be literals like <php>2</php> or <php>"foo"</php>, but also any expression , including constants or variables (this was not the case in an earlier revision of the RFC, see //Resolved issues//).
  
 <code php> <code php>
Line 84: Line 84:
 ) = $curlOptions; ) = $curlOptions;
 </code> </code>
- 
-Keys can be variables or any other expression if needed (this was not the case in an earlier version, see /Resolved Issues/): 
  
 <code php> <code php>
Line 151: 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 209: 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 230: Line 256:
 </code> </code>
  
-This would be more practical to implement than the [[rfc:named_params|Named Parameters]] RFC, and could be applied to existing function which already use the "argument bag" pattern. Destructuring syntax in parameter declarations is a feature in some other programming languages, for example [[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Pulling_fields_from_objects_passed_as_function_parameter|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.+This would be more practical to implement than the [[rfc:named_params|Named Parameters]] RFC, 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 [[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Pulling_fields_from_objects_passed_as_function_parameter|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: If we implemented this, we might want to extend the syntax to support type declarations:
Line 254: 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 281: 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.1453226676.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools