Req #75823 [Opn->Dup]: Proposal: Make a covariant types

Edit report at https://bugs.php.net/bug.php?id=75823&edit=1 ID: 75823 Updated by: cmb@php.net Reported by: hack3p at gmail dot com Summary: Proposal: Make a covariant types -Status: Open +Status: Duplicate Type: Feature/Change Request -Package: PHP Language Specification +Package: Class/Object related Operating System: irrelevant PHP Version: Irrelevant -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Duplicate of request #71825. Previous Comments: ------------------------------------------------------------------------ [2018-01-16 16:23:32] rowan dot collins at gmail dot com Hi, I recommend you have a look at the archives for the PHP-Internals mailing list, where most of the high-level decisions for the language are made. https://marc.info/?l=php-internals This particular topic has come up a couple of times, most recently here: https://marc.info/?l=php-internals&m=151359959822329&w=2 In summary, the problem is that PHP's dynamic loading of classes leads to awkward edge cases where the compiler can't know whether a particular class follows correct covariance / contravariance rules until it has loaded other classes, which in turn might require loading other classes, or the original class. It's not insurmountable, but it's not trivial either. Note that the simplest contravariance case of omitting a parameter constraint in a descendant class is now allowed in PHP 7.2. Incidentally, your second example is incorrect: return types must be covariant (at least as specific as in the parent class) but parameter types must be contravariant (at least as tolerant as in the parent class). ------------------------------------------------------------------------ [2018-01-16 15:05:23] hack3p at gmail dot com Description: ------------ The current invariative type interferes with writing idiomatic inheritance, which is implemented in many other languages. Now us have to completely remove the type of the return value and type and remove functions type hintings arguments in the parent and childs class, which helps to solve this. But in this case, in business logic now you need to manually implement type checking, since a secure application should work with the correct type. At the advent of PHP 7 with the possibility of strict typing, I hoped that the types will finally become variative. However, this did not happen. RFC by return types (https://wiki.php.net/rfc/return_types) in section "Variance and Signature Validation" has next: > This RFC originally proposed covariant return types but was changed to invariant because of a > few issues. It is possible to add covariant return types at some point in the future. I think it's time to move towards idiomatic inheritance, since it will be correct if PHP to check the types, not the programmer. Test script: --------------- Test script: https://gist.github.com/hack3p/78eeca8f50d3297bf25768a9c72cafeb Expected result: ---------------- Previous test script should be work Actual result: -------------- example 1: return type PHP Fatal error: Declaration of B::foo(): B must be compatible with A::foo(): A in ... example 2: arguments type hinting PHP Warning: Declaration of B::foo(B $bar) should be compatible with A::foo(A $bar) in ... ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=75823&edit=1