rfc:auto-capture-closure

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:auto-capture-closure [2021/05/31 20:36]
crell Add note about future optimization
rfc:auto-capture-closure [2022/07/02 13:12] (current)
imsop update "Vote" heading
Line 1: Line 1:
-====== PHP RFC: Auto-capturing multi-statement closures ====== +====== PHP RFC: Short Closures 2.0 ====== 
-  * Version: 0.9 +  * Version: 2.0 
-  * Date: 2021-03-22 +  * Date: 2022-05-25 
-  * Author: Nuno Maduro (enunomaduro@gmail.com)Larry Garfield (larry@garfieldtech.com) +  * Author: Nuno Maduro (enunomaduro@gmail.com) 
-  * Status: In Discussion+  * Author: Larry Garfield (larry@garfieldtech.com) 
 +  * Author: Arnaud Le Blanc (arnaud.lb@gmail.com) 
 +  * Status: In Voting
   * First Published at: http://wiki.php.net/rfc/auto-capture-closure   * First Published at: http://wiki.php.net/rfc/auto-capture-closure
  
 ===== Introduction ===== ===== Introduction =====
  
-Closures (also known as lambdas or anonymous functions), have become increasingly powerful and useful in PHP in recent versions In their current form they have two versions, long and short Unfortunatelythese two syntaxes have differentmutually-incompatible benefits This RFC proposes a syntax for closures that combines the benefits of both for those situations where that is warranted.+Anonymous functions in PHP can be verbose, in part due to the need to manually import used variablesThis makes code using simple closures hard to read and understand. 
 + 
 +[[rfc:arrow_functions_v2|Arrow Functions]] were introduced in PHP 7.4 as an alternative. Howeverthe single-expression limitation can lead to complex one-linersor makes Arrow Functions unfit in many use-cases that would benefit from a more concise syntax. 
 + 
 +This RFC proposes an extension of the Arrow Function syntax supporting multiple statements:
  
 <code php> <code php>
-// As of 8.0:+$guests = array_filter($users, fn ($user) { 
 +    $guest = $repository->findByUserId($user->id); 
 +    return $guest !== null && in_array($guest->id, $guestsIds); 
 +}); 
 +</code>
  
 +===== Proposal =====
 +
 +Short Closures extend Arrow Functions by allowing multiple statements enclosed in ''{'' and ''}'' instead of a single expression:
 +
 +<code php>
 +fn (parameter_list) {
 +    statement_list;
 +}
 +</code>
 +
 +The ''statement_list'' is a sequence of statements separated by semicolons. A ''return'' statement must be used to return a value.
 +
 +The syntax and behavior otherwise match those of Arrow Functions.
 +
 +==== Auto capture by-value ====
 +
 +Like Arrow Functions, Short Closures use auto capture by-value. When a variable used in the Short Closure is defined in the parent scope it will be automatically captured by-value. In the following example the functions $fn1, $fn2, and $fn3 behave the same:
 +
 +<code php>
 $y = 1; $y = 1;
  
-$fn1 = fn($x) => $x + $y; // auto-capture + single expression+$fn1 = fn ($x) => $x + $y;
  
-$fn2 = function ($x) use ($y): int // manual-capture statement list +$fn2 = fn ($x) { 
-   // ...+    return $x $y; 
 +};
  
-   return $x + $y;+$fn3 = function ($x) use ($y) { 
 +    return $x + $y;
 }; };
 </code> </code>
  
-The proposed syntax combines the auto-capture and multi-line capabilities into a single syntax:+==== No explicit capture ==== 
 + 
 +Explicit capture is not included in the new syntax.  It remains available only via the existing long-closure syntax, which only captures explicitly.  Earlier versions of this proposal included mixing auto-capture and explicit capture, but it was determined that was too confusing. 
 + 
 +==== Syntax ==== 
 + 
 +The signature accepts the same syntax as that of Arrow Functions:
  
 <code php> <code php>
-$fn3 = fn ($x)int { // auto-capture + statement list +fn () { } 
-    // ...+fn ($a, $b) { } 
 +fn ($a, ...$args{ }   // Variadic parameter 
 +fn (int $a): string // Type hints 
 +fn ($a = 42) { }        // Parameter default value 
 +fn &($a) { }            // Return by-reference 
 +fn (&$a) { }            // Pass by-reference 
 +</code>
  
-    return $+ $y+The signature must be followed by ''{'', a statement list, and ''}'': 
-};+ 
 +<code php> 
 +fn () { return 1; } 
 +fn () { print 1; } 
 +fn () { 
 +    $tmp = $a + $b
 +    return $tmp; 
 +}
 </code> </code>
  
-This RFC has also been designed in concert with the [[rfc:short-functions|Short Functions]] RFC, such that the syntax choices of both RFCs are mutually complementary in logical, predictable fashion and described below.+Note that Short Closures with a multi-statement body do not have an implicit return value. A ''return'' statement must be used to return value.
  
-===== Proposal =====+The syntax choice here is consistent with other language constructs:
  
-==== Background ====+  * ''{ ... }'' denotes a statement list, without implicit return value. 
 +  * Conversely, the ''=>'' token is followed by an expression in all circumstances.  (Arrow Functions, arrays, and ''match()''.) 
 +  * The ''fn'' keyword indicates a function that will auto-capture variables, by-value. 
 +  * The ''function'' keyword indicates a function that has no auto-capture.
  
-As of PHP 8.0, the following syntax around functions has the following meaning:+These rules are easily recognizable and learnable by developers. 
 + 
 +===== Why extend Arrow Functions? ===== 
 + 
 +Arrow Functions were added as an alternative to Anonymous Functions. The latter can be quite verbose, even when they only perform a simple operation. This is due to a large amount of syntactic boilerplate that is needed to manually import used variables with the ''use'' keyword. 
 + 
 +While Arrow Functions solve this problem to some extent, the one-expression limit can lead to one-liners with non ideal readability, or can make them unfit for some use-cases. There are ample cases where breaking an expression to 2-3 statements is required or would improve the legibility of the code. 
 + 
 +As an example, writing the following code snippet with a single-expression Arrow Function would degrade legibility, but writing it as an Anonymous Function would be cumbersome:
  
 <code php> <code php>
 +$guests = array_filter($users, fn ($user) {
 +    $guest = $repository->findByUserId($user->id);
 +    return $guest !== null && in_array($guest->id, $guestsIds);
 +});
 +</code>
  
-// A namedglobally available function+===== Discussion on auto-capture ===== 
-// No variables are auto-captured from the environment+ 
-// The body is a statement listwith possibly return statement+Auto capture was first introduced by Arrow Functions. 
-function foo($a, $b, $c): int + 
-  return $a * $b * $c;+In the pastthere had been reticence about auto-capture that has kept it out of evolutions in closures.  Mostly that has boiled down to a few concerns: Implementation difficulties, performance, and debugability
 + 
 +Implementation difficulties arise from by-reference or by-variable semantics, especially when supporting dynamic means of accessing variables like variable-variables, compact(), or eval(). In this proposal and in Arrow Functions, the implementation difficulties are eliminated by using by-value semantics and requiring dynamically accessed variables to be captured explicitly. 
 + 
 +As noted in the benchmarks section, the implementation offered here has effectively no performance impact either way
 + 
 +In the majority of cases where closures are used in practice, the code involved is short enough that debugging is not hampered by automatic capture.  They are usually only few lines longeasily small enough to fit into developer's short term memory while reading it.  What variables are captured is visually self-evident.  
 + 
 +Potential confusing behavior is further mitigated by PHP'(correct) use of by-value capture, which minimizes the potential for inadvertent confusing changes to values from closures. 
 + 
 +Furthermore, as noted PHP is unusual in requiring explicit capture.  The only other language that does so is C++.  Most languages get along fine without that extra step. 
 + 
 +For those few cases in which, for whatever reason, the developer is concerned about auto-capture reducing debugability or about accidental capture, the existing explicit-only syntax remains valid and unchanged. 
 + 
 +==== Using variables from the parent block ==== 
 + 
 +Using variables from the parent block is not unusual in PHP. We do it all the time in loops. 
 + 
 +In the following example, the loop uses three variables from the parent block. We have learned to recognize that what follows ''foreach''''for''or ''while'' keyword can do that. 
 + 
 +<code php> 
 +$guests = []; 
 +foreach ($users as $user) { 
 +    $guest = $repository->findByUserId($user->id); 
 +    if ($guest !== null && in_array($guest->id, $guestsIds)) { 
 +        $guests[] = $guest; 
 +    }
 } }
 +</code>
  
-// An anonymouslocally available function+In the following examplethe function uses two variables from the parent blockwhich should not be more surprising than with a loop once we have learned that what follows ''fn'' keyword can do thatlike we did with ''foreach''.
-// Variables are explicitly captured lexically.  +
-// The body is a statement list, with possibly return statement. +
-$foo = function ($a, $b) use ($c) { +
-  return $a * $b * $c; +
-};+
  
-// An anonymous, locally available function. +<code php> 
-// Variables are auto-captured lexically. +$guests array_filter($usersfn ($user
-// The body is a single-expression, whose value is returned. +    $guest $repository->findByUserId($user->id); 
-$foo fn($a, $b): int => $a * $b * $c;+    return $guest !== null && in_array($guest->id, $guestsIds); 
 +});
 </code> </code>
  
-That is, a function may be named or local/anonymousauto-capture or not, and a statement list or single expression.  That means there are 8 possible combinations of properties, of which only three are currently supported.+However the comparison stops here. These two examples do not behave equally with regard to side effects: Variable assignments to the ''$guest'' and ''$user'' variables in the loop can be observed after the loopbut the same is not true with the Short Closure.
  
-The [[rfc:short-functions|Short Functions]] RFC seeks to add one additional combination: named, no-capture, single-expression.+==== Capture is by-value, no unintended side-effects ====
  
-This RFC seeks to add a different combination: anonymous, auto-capture, statement list.+It is important to note that the default capture mode in Anonymous FunctionsArrow Functions, and Short Closures is by-value. This purposefully differs from the semantics commonly found in other programming languages.
  
-The remaining combinations would be:+A by-value capture means that it is not possible to modify any variables from the outer scope
  
-  * named function, auto-capture, statement list - This is of little use in practice as there is nothing to auto-capture, except potentially global variables. +<code php> 
-  * named function, auto-capture, expression - Ibid. +$a = 1; 
-  * anonymous function, manual-capture, expression - While this form would be possible to add, its use cases are limited.  The existing short-closure syntax is superior in nearly all cases.+$f = fn () { 
 +    $a++;          // Has no effect outside of the function 
 +    $tmp = $a + 1; // Has no effect outside of the function 
 +    return $tmp; 
 +};
  
-==== Auto-capture multi-statement closures ====+print $a; // prints "1" 
 +$f(); 
 +print $a; // prints "1" (again) 
 +</code>
  
-Specificallythis RFC adds the following syntax:+Conversely, the outer scope cannot modify variables in the function
  
 <code php> <code php>
-// An anonymous, locally available function. +$a = 1; 
-// Variables are auto-captured lexically. +$= fn () { 
-// The body is statement list, with possibly a return statement; +    print $a;
-$c = 1; +
-$foo = fn($a, $b):int +
-  $val = $a * $b; +
-  return $val * $c;+
 }; };
 +
 +$f();     // prints "1"
 +$a = 2;
 +$f();     // prints "1" (again)
 </code> </code>
  
-The syntax choice herein combination with the short-functions RFCleads to the following consistent syntactic meanings:+Because variables are bound by-value, the confusing behaviors often associated with closures do not exist. As an example, the following code snippet demonstrates such a behavior in JavaScript:
  
-  * The ''=>'' symbol always means "evaluates to the expression on the right," in all circumstances (Named functions, anonymous functions, arrays, and ''match()''.) +<code javascript> 
-  * ''{ ... }'' denotes a statement list, potentially ending in a ''return''. +// JavaScript 
-  * The ''function'' keyword indicates a function that has no auto-capture. +var fns = []; 
-  * The ''fn'' keyword indicates a function that will auto-capture variablesby value. +for (var i = 0; i < 3; i++) { 
-  * A function with a name is declared globally at compile time.  A function without a name is declared locally as a closure at runtime.+    fns.push(function() 
 +        console.log(i); 
 +    }); 
 +
 +for (var k in fns) { 
 +    var fn = fns[k]; 
 +    fn(); // Prints "3""3", "3" 
 +
 +</code>
  
-These rules are easily recognizable and learnable by developers.+In PHP the behavior is intuitive and less confusing:
  
-==== Why add another function mechanism? ====+<code php> 
 +// PHP 
 +$fns []; 
 +for ($i 0; $i < 3; $i++) { 
 +    $fns[] fn () { 
 +        print $i; 
 +    }; 
 +
 +foreach ($fns as $fn) { 
 +    $fn(); // Prints "0", "1", "2" 
 +
 +</code>
  
-Long Closures in PHP can be quite verboseeven when they only perform a simple operationAnd this is due to a large amount of syntactic boilerplate that the need in “long closures” to manually import used variables with the “use” keyword.+In JavaScript the same output can be obtained by declaring ''i'' with the ''let'' keyword. Using the ''var'' keywordand loops, is largely discouragedHowever ''i'' is still captured by-variable (not to be confused with by-value), so the anonymous functions can still modify the value of ''i''. A different behavior can be obtained with the ''const'' keyword.
  
-While one-line arrow functions solve this problem to some extentthere are ample cases that require a 2-3 statement body.  That is still short enough that the chances of a developer confusing in-function and out-of-function variables is very remotebut the burden of manually closing over 3-4 variables is relatively high.+In PHPthe variable is captured by-valuethus entirely avoiding the confusion.
  
-One example is when you are within a class method with multiple arguments and you want to simply return a closure that uses all the argumentsusing the “use” keyword to list all the arguments is entirely redundant and pointless.+Of coursefunctions can have side-effects when accessing mutable values such as objects or resourcesThe following example demonstrates this: 
 +<code php> 
 +$d = new DateTime();
  
-Then there are often use-cases with ''array_filter()'' and similar functions where the ''use()'' just adds visual noise to what the code actually means.+$fn1 = fn () { 
 +    $d->modify('+ 1 day'); // Has an effect on the object bound to $d 
 +};
  
-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.+$fn2 = function () use ($d) { 
 +    $d->modify('+ 1 day'); // Has an effect on the object bound to $d 
 +};
  
-==== Methods ====+$fn3 function (DateTime $d) { 
 +    $d->modify('+ 1 day'); // Has an effect on the object bound to $d 
 +}; 
 +</code>
  
-As methods cannot be anonymous, there are no impacts on methods from this RFC.  The short-functions RFC does address methods, and does so in a way that is completely consistent with the syntactic rules defined above.+===== Auto-capture semantics =====
  
-==== What about long-closures? ====+The RFC inherits the auto-capture semantics of Arrow Functions. These semantics can be stated as follows: 
  
-The existing multi-line closure syntax remains valid, and there is no intent to deprecate it.  It is likely to become less common in practice, but it still has two use cases where it will be necessary:+> Short Closures can access a snapshot of the variable bindings of their declaring scope by accessing variables literally. The snapshot is taken when the function is declared. Assignments to variables do not have an effect on the declaring scope.
  
-  * When it is desirable to capture variables explicitlysuch as to avoid name collision+This can also be stated as follows: 
-  * When it is desirable to capture a variable by reference Such use case are rare but do exist.+ 
 +> Short Closures can read variables of their declaring scope by accessing variables literally. The values of these variables are the ones that were bound to them at function declaration. Assignments to variables do not have an effect on the declaring scope. 
 + 
 +This is implemented by binding the value of the declaring scope variables to local variables in the function. This is referred to as //capture// in this RFC. 
 + 
 +This RFC leaves unspecified which variables are captured, as long as these semantics are maintained
 + 
 +==== Optimization ==== 
 + 
 +A naive approach would capture //all// the variables that are accessed literally by the closureThis will commonly capture variables that are not necessary to maintain these semantics. In the following example, the variable ''$tmp'' would be captured although this is not necessary because it is always assigned before being read (remember that variable assignments do not have an effect outside of the closure).
  
 <code php> <code php>
-// This remains the only way to capture by reference. +$tmp 5
-$1+fn () { 
-$function($a, $buse (&$c{ +    $tmp foo()
-  $c = $a * $b+    bar($tmp); 
-};+    return $tmp
 +}
 </code> </code>
  
-==== Multi-line expressions ====+This approach would result in a waste of memory or CPU usage. 
 + 
 +The implementation proposed in this RFC prevents this by attempting to capture the smallest possible set of variables necessary to maintain these semantics. In practice, Short Closures end up capturing the same set of variables that Anonymous Functions with a manually curated capture list would have captured. This was observed on the PHPStan code base by converting all Anonymous Functions to Short Closures, and looking at which variables were automatically captured after that. 
 + 
 +These implementation details are irrelevant for most purposes, as they do not have an effect on the behavior of the program, apart from the marginal cases listed in the next subsection. However, the exact behavior can be defined as follows: 
 + 
 +  * If there is a possibility that a variable may be read by the function before binding it, it is captured 
 +  * When inspecting the code, the following operations are assumed to always bind a variable without reading it: 
 +    * Variable assignments 
 +    * Variable assignments by reference 
 +    * ''global'' 
 +    * ''static'' 
 +    * ''unset()'' 
 +    * This excludes assignments to object properties (they never bind the variable), assignments to array dimensions (they read the variable) 
 +  * In all other situations in which a variable is used, it is assumed that it is read 
 + 
 +This optimization is not applied to Arrow Functions because variable bindings are unusual in these functions. 
 + 
 +==== Observable effects of capture ==== 
 + 
 +As long as the semantics are maintained, whether a variable is captured or not is largely irrelevant for most purposes, and can be observed only in marginal cases. These cases are listed here. 
 + 
 +  * When debugging: Whether a variable is captured or not may be visible in the list of variables in scope in debuggers. Captured variables are local variables in the Closure, initialized to the captured value.\\ \\ 
 +  * Via reflection: Captured variables will be visible in ReflectionFunction.\\ \\ 
 +  * Via dynamic variable access: Means to access variables dynamically, such as the variable-variable syntax or the ''compact()'' function, whose use is largely discouraged in modern PHP, can only see variables that are captured.\\ \\ 
 +  * Via destructors: Capture can extend the lifetime of objects. Optimized capture will prevent this when the variable holding the object is never read before being written by the Closure. An observable effect is that a destructor would be called later if the object was captured. Note that destructor timing is undefined in PHP, especially when reference cycles exist.\\ \\ 
 +  * Via resource usage: Capturing too much could increase memory or CPU usage. The optimized capture used in this RFC prevents this. It ends up capturing the same variables that would have been captured by a manually curated ''use'' list. 
 + 
 +==== Implementation details ==== 
 + 
 +The capture analysis used in this RFC will only capture the variables that may be read before being assigned by the function. This uses the Optimizer's implementation of [[https://en.wikipedia.org/wiki/Live-variable_analysis|live-variable analysis]]. 
 + 
 +This maintains the semantics described earlier, so an understanding of these semantics is enough to reason about Short Closures. 
 + 
 +===== Benchmarks ===== 
 + 
 +In benchmarks, the implementation in the 1.0 version of this RFC showed a notable CPU and memory increase when using auto-capturing multi-statement closure in some cases. 
 + 
 +The 2.0 version, proposed here, has only marginal impact compared to PHP 8.1, well within the margin of error for profiling tools. In some cases the profiling run shows the Short Closure version being slightly more performant, which is likely just random test jitter between runs.  We therefore conclude that the performance impact of this approach is effectively zero. 
 + 
 +The capture analysis approach described above makes Short Closures as efficient as Anonymous Functions. 
 + 
 +For more benchmark details, see: https://gist.github.com/arnaud-lb/d9adfbf786ce9e37c7157b0f9c8d8e13 
 + 
 +===== What about Anonymous Functions? ===== 
 + 
 +The existing Anonymous Function syntax remains valid, and there is no intent to deprecate it. 
 + 
 +===== Multi-line expressions =====
  
 There has been related discussion of multi-line expressions, specifically in the context of ''match()'' arms.  We considered whether multi-line expressions made sense as an alternative approach, but decided against it as that introduces considerably more edge cases both syntactically and in the engine. There has been related discussion of multi-line expressions, specifically in the context of ''match()'' arms.  We considered whether multi-line expressions made sense as an alternative approach, but decided against it as that introduces considerably more edge cases both syntactically and in the engine.
  
-As a side benefit, the syntax proposed here does offer a somewhat round-about way to have a multi-line ''match()'' arm.  This is not a deliberate feature of the RFC, but more of a convenient side-effect.+As a side benefit, the syntax proposed here does offer a somewhat round-about way to have a multi-line ''match()'' arm.  This is not a deliberate feature of the RFC, but more of a convenient side-effect noted here for completeness.
  
 <code php> <code php>
Line 142: Line 324:
 $c = ...; $c = ...;
 $ret = match ($a) { $ret = match ($a) {
-  1, 3, 5 => (fn() {+  1, 3, 5 => (fn () {
     $val = $a * $b;     $val = $a * $b;
     return $val * $c;     return $val * $c;
   })(),   })(),
-  2, 4, 6 => (fn() {+  2, 4, 6 => (fn () {
     $val = $a + $b;     $val = $a + $b;
     return $val + $c;     return $val + $c;
Line 155: Line 337:
 While sub-optimal, it may be sufficient for the few times that a multi-statement ''match()'' arm is needed. While sub-optimal, it may be sufficient for the few times that a multi-statement ''match()'' arm is needed.
  
-==== Examples ====+===== Comparison to other languages =====
  
-Closures are often used to "wrap" some behavior in other behavior.  One example provided by Mark Randall is for a throw-aware buffer The following is actual code he wrote:+As far as we are aware, only two languages in widespread use require variables to be explicitly closed over: PHP and C++.  All other major languages capture implicitly, as is proposed here.
  
-<code php> +Languages commonly capture by-variable (not to be confused with by-valueor by reference. In practice this can lead to confusing effectsespecially in loops. For that reasonPHP defaults to capturing by-valuewhich avoids this problem. This is discussed above in this RFCas well as in [[rfc:arrow_functions_v2#binding_behavior|Arrow Functions]].
-$x = function () use ($to, $library$thread$author$title, $library_name, $top_post) { +
-// ... +
-}; +
-</code>+
  
-From Mark: "That was just to get those variables inside a callback that could be  +===== History =====
-invoked inside a throw-aware buffering helper."+
  
-Another similar example is for wrapping behavior in a transaction Oftenthat is done by passing a callable to an ''inTransaction()'' method or similar.+The first discussion [[https://externals.io/message/28399|1]] around Anonymous Functions was objected to because of the lack of closures: It would be unusual for anonymous functions to not support closures, which would surprise users and limit the usefulness of the constructAt the same timeobjections against closures cited implementation difficulties and performance issues, as well as potential complexity or pitfalls most commonly found in other programming languages.
  
-<code php> +In the same and subsequent discussions [[https://externals.io/message/34040|2]] [[https://externals.io/message/38290|3]] a solution was proposed to use explicit capture with a new keyword''lexical''close in many aspects to the ''global'' keyword. Alternative syntaxes were later proposed that would allow to choose between by-reference and by-value capture, ultimately leading to the current ''use($x)'' syntax.
-public function savePost($user$date$title, $body, $tags) { +
-  return $this->db->inTransaction(function() use ($user, $date, $title, $body, $tags+
-    $this->db->query(...); +
-    $this->db->query(...); +
-    return $this->db->lastInsertId(); +
-  }); +
-+
-</code>+
  
-In this case, the ''use''d variable listing is entirely redundant and pointlessmuch the same as constructor property promotion eliminated entirely redundant boilerplate (Though admittedly, the difference there was much greater.)+It is unclear whether this was chosen because of technical concerns or concerns over semantics. Objections focusing on semantics appear to have been based on those most commonly found in other programming languages. These semantics differ significantly from what is proposed here. For instanceobjections cite the possibility of a kind of side-effects that would not exist with by-value captureDiscussions do not appear to have occurred in the light of by-value semantics.
  
-==== Comparison to other languages ====+The [[rfc:short_closures|Short Closures 1.0]] RFC was declined for three main reasons [[https://externals.io/message/88394#88507|4]]: The syntax, the lack of type declarations, and implicit capture. Objections to implicit closures appear to be based on semantics that do not exist in the current RFC.
  
-As far as we are aware, only two languages in widespread use require variables to be explicitly closed over: PHP and C++.  All other major languages capture implicitlyas is proposed here.+The [[rfc:arrow_functions_v2|Arrow Functions 2.0]] RFC was accepted with a large majority. Compared to the Short Closures 1.0 RFCit addressed the syntax and type hints concerns, limited the body to only one expression, and kept implicit closure by-value. 
 + 
 +===== Alternative implementations ===== 
 + 
 +A few people suggested implementing the same functionality via a different syntax, that is, basing it on the long-closure syntax with a ''use(*)'' or ''use(...)'' syntax to indicate "capture everything that makes sense" rather than building on the short-closure syntax which already "captures everything that makes sense." 
 + 
 +The resulting behavior in either case would be identical, making it a largely aesthetic or philosophical distinction. The authors felt that the more compact syntax is preferable, for several reasons: 
 + 
 +  - The longer form introduces more visual noise to achieve the same result. 
 +  - PHP developers have been using the ''fn()'' syntax for a number of years now, and should be sufficiently familiar with the concept of auto-capture. 
 +  - With the improved capture logicmany of the arguments for the explicit capture syntax go away. 
 +  - Using the longer ''function'' keyword without a ''use'' statement at all would be a semantic BC break, which is not acceptable. 
 +  - If converting from a single line short-lambda to a 2 line closure, switching to the long-form syntax is more work than just switching ''=>'' for ''{}''
 + 
 +For those reasons, the authors went with the ''fn()''-derived syntax shown here.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 192: Line 375:
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
  
-PHP 8.1.+PHP 8.2.
  
 ===== Open Issues ===== ===== Open Issues =====
Line 200: Line 383:
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
  
-Existing function syntax continues to work precisely as it does now.  Only new combinations are possible.+Existing function syntaxes continues to work precisely as they do now.  Only new combinations are possible.
  
 ===== Future Scope ===== ===== Future Scope =====
  
-The proposal section detailed three additional possible combinations of function functionality that are not included here.  While it is not likely that they have much use, the pattern here clearly lays out what they would be were a future RFC to try and implement them.+These are some possible future extensionsbut the authors don't necessarily endorse them.
  
-Specifically, they would be:+==== Explicit use list on Short Closures ==== 
 + 
 +It would be possible to extend the Short Closure syntax to allow an explicit use list:
  
 <code php> <code php>
-// Global scope +$fn fn () use ($a, &$b) { 
-$1;+}; 
 +</code>
  
-fn foo($a, $b): int { +One anticipated use-case is to selectively capture some variables by-reference.
-  $val = $a * $b; +
-  return $val * $c; +
-}+
  
-fn foo($a$b): int => $a * $b * $c;+There are at least two possible variations of this extension. In one of themthe use list is merged with auto-capture, so that explicit uses and auto-capture can coexist on the same function. In another the use list disables auto-capture on the function.
  
-$foo = function($a, $b) use ($c): int => $a * $b * $c; +This RFC initially proposed the first possibility. This is not included in the current version because this appeared to create confusion.
-</code>+
  
-Those versions are //not// included in this RFC.  +==== Optimize Arrow Functions ====
  
-Additionally, it is quite possible that the auto-capture logic could be improved to be smarter about what variables to capture and which not to.  Such an optimization can be done at any time as it has no functional impact on user code.+This RFC proposes an optimized auto-capture. It would be possible to apply this optimization to Arrow Functions as well, but this would be a breaking change in some rare cases.
  
-===== Proposed Voting Choices =====+This is not included in this RFC because most Arrow Functions would not benefit from this.
  
-This is a simple Yes/No vote, requiring 2/3 to pass.+===== Vote ===== 
 + 
 +This is a simple Yes/No vote, requiring 2/3 to pass.  Vote ends on 15 July 2022. 
 + 
 + 
 +<doodle title="Add Short Closures as described in PHP 8.2?" auth="jrf" voteType="single" closed="false"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
  
-Pull Request: https://github.com/php/php-src/pull/6246+Pull Request: https://github.com/php/php-src/pull/8330
  
 ===== Implementation ===== ===== Implementation =====
Line 242: Line 432:
  
 ===== References ===== ===== References =====
-[[rfc:short-functions|PHP RFC: Short Functions]]+  * [[rfc:short-functions|PHP RFC: Short Functions]]   
 +  * [[rfc:arrow_functions_v2|PHP RFC: Arrow Functions]]   
 +  * [[rfc:short_closures|PHP RFC: Short Closures 1.0]] 
 + 
 +===== Changelog ===== 
 + 
 +2.0: Updated for new patch; reduced discussion of short-function RFC and related topics; expanded discussion of the capture rules and noted benchmarks showing minimal performance impact; renamed to "Short Closures 2.0"
  
-===== Rejected Features ===== 
-Keep this updated with features that were discussed on the mail lists. 
rfc/auto-capture-closure.1622493382.txt.gz · Last modified: 2021/05/31 20:36 by crell