rfc:first_class_callable_syntax

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:first_class_callable_syntax [2021/06/29 07:53] nikicrfc:first_class_callable_syntax [2021/07/16 09:55] (current) nikic
Line 2: Line 2:
   * Date: 2021-05-20   * Date: 2021-05-20
   * Author: Nikita Popov <nikic@php.net>, Joe Watkins <krakjoe@php.net>   * Author: Nikita Popov <nikic@php.net>, Joe Watkins <krakjoe@php.net>
-  * Status: Under Discussion+  * Status: Implemented
   * Target Version: PHP 8.1   * Target Version: PHP 8.1
   * Implementation: https://github.com/php/php-src/pull/7019   * Implementation: https://github.com/php/php-src/pull/7019
Line 30: Line 30:
 $fn = fn(...$args) => Foo::method(...$args); $fn = fn(...$args) => Foo::method(...$args);
 </PHP> </PHP>
 +
 +The syntax is forward-compatible with [[rfc:partial_function_application|partial functions application]].
  
 ===== Proposal ===== ===== Proposal =====
Line 90: Line 92:
 ==== Nullsafe calls ==== ==== Nullsafe calls ====
  
-The first-class callable syntax cannot be combined with nullsafe method calls''$obj?->method(...)'' results in a compile-time error.+The first-class callable syntax cannot be combined with the nullsafe operatorBoth of the following result in a compile-time error: 
 + 
 +<PHP> 
 +$obj?->method(...)
 +$obj?->prop->method(...); 
 +</PHP>
  
 The ''$obj?->method(...)'' syntax has two potential interpretations: The ''$obj?->method(...)'' syntax has two potential interpretations:
Line 112: Line 119:
 ==== Partial Function Application ==== ==== Partial Function Application ====
  
-This RFC is intended as an alternative to the [[rfc:partial_function_application|partial functions application (PFA)]] RFC. I believe that PFA use-cases can be divided into roughly three categories:+This RFC can be seen as an alternative to the [[rfc:partial_function_application|partial functions application (PFA)]] RFC. I believe that PFA use-cases can be divided into roughly three categories:
  
 The first is the use of PFA to acquire a callable, without partially applying any arguments. I believe that the vast majority of PFA uses would be for this purposes. This RFC proposes to provide special support for this use-case **only**. The first is the use of PFA to acquire a callable, without partially applying any arguments. I believe that the vast majority of PFA uses would be for this purposes. This RFC proposes to provide special support for this use-case **only**.
Line 150: Line 157:
 I think that the existing syntax is already sufficiently concise that there is no strong need to introduce an even shorter one. I think that the existing syntax is already sufficiently concise that there is no strong need to introduce an even shorter one.
  
-As such, I believe that adding a first-class callable syntax, and using the original approach to the pipe operator, would give us most of the benefit of PFA at a much lower complexity cost. The PFA proposal has gone through many iterations, because nailing down the precise semantics turned out to be surprisingly hard. According to Joe Watkins (the implementer of the PFA RFC), the final semantics we have arrived at (which, at the time of this writing, are not reflected in the PFA proposal itself) will also carry lot of implementation complexity.+As such, I believe that adding a first-class callable syntax, and using the original approach to the pipe operator, would give us most of the benefit of PFA at a much lower complexity cost. The PFA proposal has gone through many iterations, because nailing down the precise semantics turned out to be surprisingly hard. The final proposal is simple on conceptual level, but very involved when it comes to detailed behavior.
  
 ==== Syntax choice ==== ==== Syntax choice ====
  
-The proposed syntax is forward-compatible with the latest iteration of the PFA proposal (which, at the time of this writing, is not yet reflected in the RFC). As such, it would be possible to expand it into a full PFA feature in the future.+The proposed syntax is forward-compatible with the latest iteration of the PFA proposal. As such, it would be possible to expand it into a full PFA feature in the future.
  
 The call-based syntax also has the advantage that it is unambiguous: It represents exactly the callable that would be invoked by a direct call of the same syntax. This cannot be said of some other syntax choices that have been discussed in the past, for example: The call-based syntax also has the advantage that it is unambiguous: It represents exactly the callable that would be invoked by a direct call of the same syntax. This cannot be said of some other syntax choices that have been discussed in the past, for example:
Line 210: Line 217:
 ===== Vote ===== ===== Vote =====
  
-Yes/No.+Voting started on 2021-07-02 and closes on 2021-07-16. 
 + 
 +<doodle title="Introduce first-class callable syntax as proposed?" auth="nikic" voteType="single" closed="true"> 
 +   Yes 
 +   No 
 +</doodle> 
rfc/first_class_callable_syntax.1624953187.txt.gz · Last modified: 2021/06/29 07:53 by nikic