rfc:structural-typing-for-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:structural-typing-for-closures [2023/04/13 16:09] – nicolasgrekasrfc:structural-typing-for-closures [2023/04/20 16:16] (current) – nicolasgrekas
Line 5: Line 5:
   * Author: Larry Garfield <crell@php.net>, Nicolas Grekas <nicolasgrekas@php.net>   * Author: Larry Garfield <crell@php.net>, Nicolas Grekas <nicolasgrekas@php.net>
   * Status: Draft   * Status: Draft
-  * First Published at: https://wiki.php.net/rfc/structural-typing-for-closures    +  * First Published at: https://wiki.php.net/rfc/structural-typing-for-closures 
 +  * Implementation: TBD
  
 ===== Introduction ===== ===== Introduction =====
Line 13: Line 14:
 ===== Proposal ===== ===== Proposal =====
  
-Given an interface with only an ''%%__invoke()%%'' method, if a parameter, return, property, or instanceof operation is typed against that interface, and a closure is passed or returned as a value, the engine checks the signature of the closure to ensure it satisfies the contract defined by the interface.+Given an interface with only an ''%%__invoke()%%'' method, if a parameter, return, property, or instanceof operation is typed against that interface, and a closure is passed or returned as a value, the engine checks the signature of the closure to ensure it satisfies the contract defined by the interface. This check would also happen when using ''is_subclass_of()'' and ''is_a()''.
  
 This would encourage developers to define more explicit and expressive type declarations, which can lead to better code maintainability and fewer runtime errors. This would encourage developers to define more explicit and expressive type declarations, which can lead to better code maintainability and fewer runtime errors.
Line 44: Line 45:
 ===== Open Questions ===== ===== Open Questions =====
  
-  * What would be the performance impact of adding this feature to the language, considering the engine would need to verify the closure signatures at runtime? +  * What would be the performance impact of adding this feature to the language, considering the engine would need to verify the closure signatures at runtime? Could this be cached internally? 
-  * Should reflection know something about this?+  * Should reflection/''class_implements()'' know something about this? We think not at this point because those are defined in the context of nominal typing only. 
 +  * In order the achieve the required check, the engine would need to autoload the interface/type at call time or when using ''instanceof''. The engine might not be prepared for that.
  
 ===== Future Scope ===== ===== Future Scope =====
  
   * Auto-cast closures to interfaces that have a single method that is not necessarily named ''%%__invoke()%%''   * Auto-cast closures to interfaces that have a single method that is not necessarily named ''%%__invoke()%%''
-  * Allow closures to declare the interface they implement as in e.g. ''function () implements FooInterface {}''+  * Allow closures to declare the interface they implement as in e.g. ''function () implements FooInterface {}''. See https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
Line 56: Line 58:
 This RFC proposes a straight Yes/No vote. A two-thirds majority is required for acceptance. This RFC proposes a straight Yes/No vote. A two-thirds majority is required for acceptance.
  
-===== Implementation ===== 
- 
-TBD 
rfc/structural-typing-for-closures.1681402167.txt.gz · Last modified: 2023/04/13 16:09 by nicolasgrekas

Page Tools