rfc:short_closures

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_closures [2015/05/01 19:21] bwoebirfc:short_closures [2017/09/22 13:28] (current) – external edit 127.0.0.1
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 78: 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 255: 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 270: Line 280:
     private $bar:     private $bar:
  
-    getBar ~> $this->bar;+    getBar() ~> $this->bar;
     setBar($bar) ~> $this->bar = $bar;     setBar($bar) ~> $this->bar = $bar;
 } }
Line 285: 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.1430508109.txt.gz · Last modified: 2017/09/22 13:28 (external edit)