rfc:short-functions

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:short-functions [2021/03/01 18:43] – Update related RFCs for more supporting evidence. crellrfc:short-functions [2021/06/15 22:29] (current) – Fix RFC status ilutov
Line 3: Line 3:
   * Date: 2020-10-20   * Date: 2020-10-20
   * Author: Larry Garfield (larry@garfieldtech.com)   * Author: Larry Garfield (larry@garfieldtech.com)
-  * Status: Draft +  * Status: Declined 
-  * First Published at: http://wiki.php.net/rfc/short-functions+  *  First Published at: http://wiki.php.net/rfc/short-functions
  
 ===== Introduction ===== ===== Introduction =====
Line 19: Line 19:
 function add(int $a, int $b): int  function add(int $a, int $b): int 
 { {
-    return $a + b;+    return $a + $b;
 } }
 </code> </code>
Line 48: Line 48:
 Functions are simpler than lambdas, as there is no need for closing over variables contextually.  Therefore this patch is implemented 100% in the lexer, and thus should have no performance impact whatsoever. Functions are simpler than lambdas, as there is no need for closing over variables contextually.  Therefore this patch is implemented 100% in the lexer, and thus should have no performance impact whatsoever.
  
 +==== Consistency with closure syntax ====
 +
 +This RFC is designed to complement the [[rfc:auto-capture-closure|Auto-capturing multi-statement closures]] RFC.  Both stand on their own and offer independent benefits.  However, they have been designed such that their syntax is complementary and consistent.  Specifically:
 +
 +  * The ''=>'' sigil always means "evaluates to the expression on the right," in all circumstances.  (Named functions, anonymous functions, arrays, and ''match()''.)
 +  * ''{ ... }'' denotes a statement list, potentially ending in a ''return''.
 +  * The ''function'' keyword indicates a function that has no auto-capture.
 +  * The ''fn'' keyword indicates a function that will auto-capture variables, by value.
 +  * A function with a name is declared globally at compile time.  A function without a name is declared locally as a closure at runtime.
 +
 +These rules are easily recognizable and learnable by developers.
 +
 +(Further discussion of the possible permutations, and which are not useful to begin with, is in the Auto-capturing Closures RFC.)
  
 ==== Reasoning ==== ==== Reasoning ====
Line 55: Line 68:
 Expressions are becoming increasingly capable, too.  match() expressions and throw expressions in PHP 8.0, plus proposals such as [[rfc:pipe-operator-v2|PHP RFC: Pipe Operator v2]], are collectively making it easier to write expressive expressions.  Enumeration methods are likely to consist primarily of a single match() statement.  This improvement is a part of that larger trend. Expressions are becoming increasingly capable, too.  match() expressions and throw expressions in PHP 8.0, plus proposals such as [[rfc:pipe-operator-v2|PHP RFC: Pipe Operator v2]], are collectively making it easier to write expressive expressions.  Enumeration methods are likely to consist primarily of a single match() statement.  This improvement is a part of that larger trend.
  
-=== Pure functions ===+The trend in PHP in recent years has been toward more compact but still readable syntax that eliminates redundancy.  Property promotion, arrow functions, the nullsafe operator, and similar recent well-received additions demonstrate this trend.  This RFC seeks to continue that trend to make PHP more pleasant to write while still being just as clear to read. 
 + 
 +==== Pure functions ====
  
 Expression functions are also more likely to be pure, and thus avoid mutable state.  That cannot be guaranteed as it is possible to write single-expression functions that "leak" via global variables, like so: Expression functions are also more likely to be pure, and thus avoid mutable state.  That cannot be guaranteed as it is possible to write single-expression functions that "leak" via global variables, like so:
Line 64: Line 79:
  
 function fullName(string $first, string $last): string function fullName(string $first, string $last): string
-  => sprintf('%s %s %d', $first, $last, $GLOBALS['called']++;+  => sprintf('%s %s %d', $first, $last, $GLOBALS['called']++);
 </code> </code>
  
 However, such code would be readily apparent as using global mutable state, and is easily avoided.  That makes short-functions more reliably "safe" and thus less prone to stateful errors. However, such code would be readily apparent as using global mutable state, and is easily avoided.  That makes short-functions more reliably "safe" and thus less prone to stateful errors.
  
-==== Examples ====+===== Examples =====
  
 Below are some examples of "long form" current code and what the short function equivalent would be.  This RFC asserts that the shorter version is more concise and readable.  All code is using standard PSR-12 formatting. Below are some examples of "long form" current code and what the short function equivalent would be.  This RFC asserts that the shorter version is more concise and readable.  All code is using standard PSR-12 formatting.
  
-=== Match functions ===+==== Match functions ====
  
 A function that encapsulates a match() expression. A function that encapsulates a match() expression.
Line 102: Line 117:
 </code> </code>
  
-=== Enum methods ===+==== Enum methods ====
  
 In practice, most enum methods are likely to contain only a match expression, the evaluated value of which should be returned.  That makes them a good candidate for short functions and eliminating visual clutter. In practice, most enum methods are likely to contain only a match expression, the evaluated value of which should be returned.  That makes them a good candidate for short functions and eliminating visual clutter.
Line 133: Line 148:
 </code> </code>
  
-=== Getter methods ===+==== Getter methods ====
  
-Many classes consist primarily or almost entirely out of methods that either return a property, or some computation off of a property.  With short-functions, that becomes considerably more concise.+Many classes consist primarily or almost entirely of methods that either return a property, or some computation off of a property.  With short-functions, that becomes considerably more concise.
  
 <code php> <code php>
Line 180: Line 195:
 </code> </code>
  
-=== Functional code ===+==== Functional code ====
  
 <code php> <code php>
Line 204: Line 219:
 </code> </code>
  
-=== Conditional methods ===+==== Conditional methods ====
  
 A common refactoring technique is to take a complex conditional in an if statement and move it to its own method, so it can be given a self-descriptive name.  Such methods are naturally single-expression.  Thus, well-factored code is likely to have a large percentage of its functions and methods be single-expression, and thus candidates for short functions. A common refactoring technique is to take a complex conditional in an if statement and move it to its own method, so it can be given a self-descriptive name.  Such methods are naturally single-expression.  Thus, well-factored code is likely to have a large percentage of its functions and methods be single-expression, and thus candidates for short functions.
Line 229: Line 244:
 Which is more simple and compact than a full function body. Which is more simple and compact than a full function body.
  
-=== Decorating functions in live code ===+==== Decorating functions in live code ====
  
 Often times, methods exist that are just delegating to some other method, either in the same object or a composed object.  These are also good candidates for a more compact syntax.  For example, here's some code pulled from the Drupal database layer's Select query builder.  (These are all real methods; I've just stripped out the comments and converted them to PSR-12 style.) Often times, methods exist that are just delegating to some other method, either in the same object or a composed object.  These are also good candidates for a more compact syntax.  For example, here's some code pulled from the Drupal database layer's Select query builder.  (These are all real methods; I've just stripped out the comments and converted them to PSR-12 style.)
Line 397: Line 412:
 The => operator has de facto become the "maps to this expression" operator: Short lambdas use it, match() uses it, array literals use it...  It seemed the natural choice.  Anything else would have been more confusing. The => operator has de facto become the "maps to this expression" operator: Short lambdas use it, match() uses it, array literals use it...  It seemed the natural choice.  Anything else would have been more confusing.
  
-The author favors using "function" as a keyword for all named functions rather than "fn", on the grounds that it would introduce additional visual clutter in classes that make use of both short and long functions, and increase the work when a short function needs to be modified into a long function.  However, if the consensus is to use "fn" instead that is also possible.  An alternate PR that does so, courtesy of Sara Golemon, is also available below.  It also confines all its changes to the lexer so all the same arguments in its favor apply.+The use of the ''fn'' keyword was also considered, but rejected.  In context, ''fn'' currently indicates that auto-capture will happen for variables from the lexical scope.  (See the discussion above.)  However, a named function has no meaningful values to capture, making ''function'' more appropriate.
  
-As of this time, this RFC is to use "function" for short named functions. +===== Related RFCs =====
- +
-==== Related RFCs ====+
  
 A number of other RFCs in active consideration would complement short functions.  They may or may not pass, but if they did then they would benefit from short functions without any further effort. A number of other RFCs in active consideration would complement short functions.  They may or may not pass, but if they did then they would benefit from short functions without any further effort.
  
-=== Piped functions ===+==== Piped functions ====
  
 The [[rfc:pipe-operator-v2|pipe operator]] |> is still pending in an RFC, but the feedback on it before was generally positive.  Short functions would allow a function to be easily defined as the composition of several other functions. The [[rfc:pipe-operator-v2|pipe operator]] |> is still pending in an RFC, but the feedback on it before was generally positive.  Short functions would allow a function to be easily defined as the composition of several other functions.
Line 427: Line 440:
 </code> </code>
  
-Which is a really nice way to build up a pipeline through composition.  (Modulo PHP's clumsy way of referencing functions by name, which is a separate matter being addressed elsewhere.)+Which is a really nice way to build up a pipeline through composition.  Modulo PHP's clumsy way of referencing functions by name, which is a separate matter that would be addressed by the [[rfc:partial_function_application|Partial Function Application]] RFC.  The three RFCs together would allow for this:
  
-=== clone-with ===+<code php> 
 +function doAThing(User $u) => $u 
 +    |> step1(?)  
 +    |> step2(?) 
 +    |> step3($val, ?)  
 +    |> step4(?, $var) 
 +; 
 +</code> 
 + 
 + 
 +==== clone-with ====
  
 Although no formal RFC has been proposed, Máté had discussed a ''clone with'' syntax ([[https://github.com/php/php-src/pull/6538|code]], [[https://externals.io/message/112624|thread]]) that would create a useful, single-expression clone-with-modification operation.  That is an excellent candidate for short-function "withX" methods. Although no formal RFC has been proposed, Máté had discussed a ''clone with'' syntax ([[https://github.com/php/php-src/pull/6538|code]], [[https://externals.io/message/112624|thread]]) that would create a useful, single-expression clone-with-modification operation.  That is an excellent candidate for short-function "withX" methods.
Line 437: Line 460:
 { {
     public function __construct(private int $x, private int $y) {}     public function __construct(private int $x, private int $y) {}
-     +
-    +
     public function getX(): int => $this->x;     public function getX(): int => $this->x;
     public function getY(): int => $this->y;     public function getY(): int => $this->y;
Line 445: Line 467:
     public function withY($y): static => clone($this) with {y: $y};     public function withY($y): static => clone($this) with {y: $y};
 } }
 +</code>
  
 Thus making many cases of wither methods just as trivial to write as getter methods. Thus making many cases of wither methods just as trivial to write as getter methods.
- 
-</code> 
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 466: Line 487:
 This is a simple up-or-down vote, requiring 2/3 approval to pass. This is a simple up-or-down vote, requiring 2/3 approval to pass.
  
-===== Patches and Tests =====+Voting started 2021-05-31 and closes 2021-06-14.
  
-[[https://github.com/php/php-src/pull/6221|Pull request with the code.]]+<doodle title="Include short-function syntax in PHP" auth="crell" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
-[[https://github.com/php/php-src/pull/6379|Alternate PR that uses fn instead of function]]+===== Patches and Tests =====
  
-Pull request for the spec still to come. +[[https://github.com/php/php-src/pull/6221|Pull request with the code.]]
- +
-===== Implementation ===== +
-After the project is implemented, this section should contain  +
-  - the version(s) it was merged into +
-  - a link to the git commit(s) +
-  - a link to the PHP manual entry for the feature +
-  - a link to the language specification section (if any) +
- +
-===== References ===== +
-Links to external references, discussions or RFCs+
  
-===== Rejected Features ===== 
-Keep this updated with features that were discussed on the mail lists. 
rfc/short-functions.1614624235.txt.gz · Last modified: 2021/03/01 18:43 by crell

Page Tools