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
Next revisionBoth sides next revision
rfc:short-functions [2021/03/01 18:43] – Update related RFCs for more supporting evidence. crellrfc:short-functions [2021/03/26 14:13] – crell
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: In Discussion 
-  * 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 64: Line 78:
  
 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>
  
Line 397: Line 411:
 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 ====
Line 445: Line 457:
     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 469: Line 480:
  
 [[https://github.com/php/php-src/pull/6221|Pull request with the code.]] [[https://github.com/php/php-src/pull/6221|Pull request with the code.]]
- 
-[[https://github.com/php/php-src/pull/6379|Alternate PR that uses fn instead of function]] 
- 
-Pull request for the spec still to come. 
  
 ===== Implementation ===== ===== Implementation =====
rfc/short-functions.txt · Last modified: 2021/06/15 22:29 by ilutov

Page Tools