Re: Re: [RFC][Vote Cancellation] Return Types

On Fri, Nov 7, 2014 at 7:20 PM, Levi Morrison <levim@php.net> wrote: > > A bug was discovered in the implementation of the return types RFC[1] > > that cannot be fixed by the current implementation. A strategy for > > fixing the bug has been identified but alters some noticeable behavior > > in PHP-land. I do not want people to feel like I did a bait-and-switch > > move during voting phase, so I have cancelled the vote while this > > issue is being fixed. More information about the bug and the strategy > > for fixing it will be published soon. > > Here is some more information on the bug: > > The following code does a covariance check on B::foo(), because it > needs to ensure that C is compatible with its parent method A::foo(), > which returns a B. However, C does not exist at the moment that the > check is performed and an error is emited saying that it could not > find class C. If these were split into separate files and autoloaded > the current solution would work. > > <?php > class A { > function foo(): B {} > } > class B extends A { > function foo(): C {} > } > class C extends B { > function foo(): C {} > } > > Note that parameters do not have this issue because they are > invariant, meaning that inheritors have to exactly match the parent > type. I feel that covariance is a necessary feature for return types > It's not especially necessary. C# uses invariant return types. Thanks. Dmitry. > to work, so the voting has been cancelled while this is fixed. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >