rfc:parameter-no-type-variance

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:parameter-no-type-variance [2016/11/21 09:32]
kelunik Draft → Under Discussion
rfc:parameter-no-type-variance [2017/09/22 13:28] (current)
Line 1: Line 1:
-====== PHP RFC: Your Title Here ====== +====== PHP RFC: Parameter Type Widening ====== 
-  * Version: 0.1.1 +  * Version: 0.3 
-  * Date: 2016-11-21 +  * Date: 2017-01-03 
-  * Author: Niklas Keller <me@kelunik.com> +  * Authors: Niklas Keller <me@kelunik.com> 
-  * Status: Under Discussion+  * Status: Implemented (7.2)
   * First Published at: http://wiki.php.net/rfc/parameter-no-type-variance   * First Published at: http://wiki.php.net/rfc/parameter-no-type-variance
- 
-===== Introduction ===== 
-PHP doesn't currently allow variance for parameters as checking these for compatibility isn't possible on compile time. This limitation is caused by autoloading and doesn't allow widening the accepted parameters. 
  
 ===== Proposal ===== ===== Proposal =====
-This RFC proposes to allow ommiting the type entirely in a subclass, as dropping all parameter constraints is always valid according to the LSP principle.+PHP currently doesn't allow any variance of parameter types when checking whether a method implemented in a class is compatible with the method defined either in the parent class or interface. 
 + 
 +This RFC proposes to allow omitting a type entirely in a subclass, as dropping all parameter constraints is always valid according to the contravariance rule. 
 + 
 +Implementing this RFC would allow libraries to be upgraded to use type declarations in their method signatures. Currently adding types to a method of a class in a library would break any code that extends that class. 
 + 
 +This would provide an easier upgrade path for libraries to start using scalar types, to replace manual checks being done inside the methods, without requiring an update for all sub-classes. 
 + 
 +Another example of this being useful is ''DateTime::createFromFormat()''. This method is already documented to accept only a class of type ''DateTimeZone'' as the 3rd parameter in the manual, but the type declaration is not actually present in the implementation. 
 + 
 +A change was made to the ''DateTime::createFromFormat()'' to add the ''DateTimeZone'' type to the 3rd parameter. However, this change had to be reverted, as all classes extending ''DateTime'' currently don't have this type declaration, so they started throwing a method signature mismatch warning. This RFC would allow the ''DateTimeZone'' type to be added to the 3rd parameter, without breaking code that extends the ''DateTime'' class. 
  
 ==== Example ==== ==== Example ====
Line 21: Line 29:
 } }
  
-class IterableClass extends ArrayClass { 
-  // This implementation also accepts Traversable. 
-  // Variance is already possible in this special case using "iterable". 
-  public function foo(iterable $foo) { /* ... */ } 
-} 
  
 +// This RFC proposes allowing the type to be widened to be untyped aka any
 +// type can be passed as the parameter.
 +// Any type restrictions can be done via user code in the method body.
 class EverythingClass extends ArrayClass { class EverythingClass extends ArrayClass {
-  // This implementation accepts all values. 
-  // Restrictions may be done via user code in the method body. 
-  // Variance is currently not allowed, it throws a warning if parent or child miss a type. 
   public function foo($foo) { /* ... */ }   public function foo($foo) { /* ... */ }
 } }
Line 47: Line 50:
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
-Next minor version, currently 7.2.+Next version, currently 7.2.
  
-===== RFC Impact ===== +===== Future Scope ===== 
-==== To SAPIs ==== +Unfortunately "true" contravariance for class types isn't part of this RFC, as implementing that is far more difficult, and would require additional rules about autoloading and/or class compilation, which might only be acceptable at a major release.
-None.+
  
-==== To Existing Extensions ==== +===== Voting ===== 
-None.+Requires a 2/3 majority.
  
-==== To Opcache ==== +<doodle title="Parameter Type Widening" auth="kelunik" voteType="single" closed="true"> 
-None.+   * Yes 
 +   * No 
 +</doodle>
  
-==== New Constants ==== +Voting started on 9th of January but has been stopped due to the mailing list failures. Voting has been resumed on 11th of January and has ended on 31th of January.
-None.+
  
-==== php.ini Defaults ==== +===== Patches and Tests =====
-None.+
  
-===== Open Issues ===== +  * https://github.com/php/php-src/pull/2265
-None. +
- +
-===== Future Scope ===== +
-In the future there might be support for contra-variance co-variance for parameters return types. +
- +
-===== Proposed Voting Choices ===== +
-Requires a 2/3 majority. +
- +
-===== Patches and Tests ===== +
-TBD.+
  
 ===== Implementation ===== ===== Implementation =====
-TBD+  - Merged into PHP 7.2 
- +  - https://github.com/php/php-src/commit/2edc3cf8d2dd75501bf1049cf1b3ca57f11f1234
-===== References ===== +
-None. +
- +
-===== Rejected Features ===== +
-None.+
rfc/parameter-no-type-variance.1479720741.txt.gz · Last modified: 2017/09/22 13:28 (external edit)