rfc:short_closures

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:short_closures [2015/05/01 18:53]
bwoebi
rfc:short_closures [2017/09/22 13:28] (current)
Line 3: Line 3:
   * Date: 2015-05-01   * Date: 2015-05-01
   * Author: Bob Weinand, bobwei9@hotmail.com   * Author: Bob Weinand, bobwei9@hotmail.com
-  * Status: ​Draft+  * Status: ​Declined / Withdrawn in favor of http://​wiki.php.net/​rfc/​arrow_functions
   * First Published at: http://​wiki.php.net/​rfc/​short_closures   * First Published at: http://​wiki.php.net/​rfc/​short_closures
  
Line 57: Line 57:
 </​code>​ </​code>​
  
-Concrete syntax is (~> is right associative with lowest possible ​associativity):+In case of no parameters, an empty parenthesis pair is needed. 
 +<code php> 
 +~> 2 * 3; // Unexpected T_TILDED_ARROW 
 +() ~> 2 * 3; // correct, will return 6 when called 
 +</​code>​ 
 + 
 +Concrete syntax is (~> is right associative with lowest possible ​precedence):
 <​code>​ <​code>​
   ( parameter_list ) ~> expression   ( parameter_list ) ~> expression
Line 72: Line 78:
  
 Also, parameter_list does //not// include default values nor type hints. See also the 'Type Hints and Return Types' section at the bottom. ​ Also, parameter_list does //not// include default values nor type hints. See also the 'Type Hints and Return Types' section at the bottom. ​
 +
 +//​Discussion Point: the { statements } syntax//
 +This RFC stance is that chained short Closures followed by a full Closure would look quite weird: ''​$foo ~> $bar ~> function ($baz) use ($foo, $bar) { /* ... */ }''​. Instead of a nicer ''​$foo ~> $bar ~> $baz ~> { /* ... */ }''​. Which is why they are supported. That syntax is **not** an invitation to randomly abuse it and use it in totally inappropriate places.
 +
 +//​Discussion Point: single parameter//
 +While it might appear not consistent, with any other number of parameters, a lot of languages having extra short Closures allow this. Also, Closures with just one parameter are relatively common, so this RFC author thinks it is worth supporting that.
  
 ==== Variable binding ==== ==== Variable binding ====
Line 170: Line 182:
  
 sumEventScores($events,​ $scores); sumEventScores($events,​ $scores);
 +</​code>​
 +
 +==== Lazy evaluation ====
 +It may be necessary to have code only evaluated under specific conditions, like debugging code:
 +<code php>
 +function runDebug(callable $func) {
 +    /* only run under debug situations, but don't let it interrupt program flow, just log it */
 +    if (DEBUG) {
 +        try {
 +            $func();
 +        } catch (Exception $e) { /*... */ }
 +    }
 +}
 +
 +$myFile = "/​etc/​passwd";​
 +
 +/* Old code */
 +runDebug(function() use ($myFile) { /* yeah, we have to use use ($myFile) here, which isn't really helpful in this context */ 
 +    if (!file_exists($myFile)) {
 +        throw new Exception("​File $myFile does not exist..."​);​
 +    }
 +});
 +
 +/* New code */
 +runDebug(() ~> {
 +    if (!file_exists($myFile)) {
 +        throw new Exception("​File $myFile does not exist..."​);​
 +    }
 +});
 +
 +/* still continue here, unlike an assert which would unwind the stack frame here ... */
 </​code>​ </​code>​
  
 ==== Partial application ==== ==== Partial application ====
-The short hand syntax makes it easier to write functional code like a reducer by using the ability of shorthand anonymous functions to be chained together easily.+The shorthand ​syntax makes it easier to write functional code like a reducer by using the ability of shorthand anonymous functions to be chained together easily.
  
 Current syntax: Current syntax:
Line 218: Line 261:
 return [$x => $x * 2]; return [$x => $x * 2];
 </​code>​ </​code>​
 +
 +Additionally,​ I was asked to not reuse the ''​%%==>​%%''​ syntax (http://​chat.stackoverflow.com/​transcript/​message/​25421648#​25421648) as Hack is already using it. Hence ''​~>''​ looks like a great alternative.
 +
 +Also, Hack has some possibilities of typing here, which do not work with PHP, due to technical reasons. Regarding forward compatibility,​ we might have to choose another syntax than Hack here to resolve these issues. It'd end up being the same operator, with a very similar syntax, potentially confusing. Furthermore using the same syntax than Hack here might lead users to expect types working here and getting really confused.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 233: Line 280:
     private $bar:     private $bar:
  
-    getBar ~> $this->​bar;​+    getBar() ~> $this->​bar;​
     setBar($bar) ~> $this->​bar = $bar;     setBar($bar) ~> $this->​bar = $bar;
 } }
Line 248: Line 295:
 As an alternative,​ the current syntax for defining Closures still can be used here.  As an alternative,​ the current syntax for defining Closures still can be used here. 
  
-===== Proposed Voting Choices ​=====+===== Vote =====
 This RFC is a language change and as such needs a 2/3 majority. This RFC is a language change and as such needs a 2/3 majority.
  
-It will be a simple yes/no vote.+Voting opened September 22th, 2015 and will remain open until October 2nd, 2015. 
 + 
 +<doodle title="​Short Closures"​ auth="​bwoebi"​ voteType="​single"​ closed="​true">​ 
 +   * Yes 
 +   * No 
 +</​doodle>​
  
 ===== Patch ===== ===== Patch =====
 Pull request is at https://​github.com/​php/​php-src/​pull/​1254 Pull request is at https://​github.com/​php/​php-src/​pull/​1254
rfc/short_closures.1430506418.txt.gz · Last modified: 2017/09/22 13:28 (external edit)