[RFC][Vote Cancellation] Return Types

Hi Levi,

thanks for doing "the right thing"[tm] and cancelling the vote to open up the discussion.

[...]

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 {}
}

I could see us documenting the behaviour as an existing limitation as I would guess that it will not be a huge issue in real life most likely anyway because of composer and PSR-1/PSR-4.

cu,
Lars

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.