====== PHP RFC: Parameter Type Widening ====== * Version: 0.3 * Date: 2017-01-03 * Authors: Niklas Keller * Status: Implemented (7.2) * First Published at: http://wiki.php.net/rfc/parameter-no-type-variance ===== Proposal ===== 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 ==== **Current Result** ''Warning: Declaration of EverythingClass::foo($foo) should be compatible with ArrayClass::foo(array $foo) in %s on line 18'' **Proposed Result** Compiles without a warning. ===== Backward Incompatible Changes ===== None. ===== Proposed PHP Version(s) ===== Next version, currently 7.2. ===== Future Scope ===== 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. ===== Voting ===== Requires a 2/3 majority. * Yes * No 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. ===== Patches and Tests ===== * https://github.com/php/php-src/pull/2265 ===== Implementation ===== - Merged into PHP 7.2 - https://github.com/php/php-src/commit/2edc3cf8d2dd75501bf1049cf1b3ca57f11f1234