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.
<?php class ArrayClass { public function foo(array $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 { public function foo($foo) { /* ... */ } }
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.
None.
Next version, currently 7.2.
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.
Requires a 2/3 majority.
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.