On Wed, Mar 10, 2021, at 12:06 PM, Matthew Brown wrote:
> Hey,
>
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools inside docblocks, and we
> feel there's a good argument for it to be supported by PHP itself.
>
> Thanks,
>
> Matt & Ondřej
My main concern is around the covariance of inheritance. The example given:
abstract class Person
{
abstract public function hasAgreedToTerms(): bool;
}
class Kid extends Person
{
public function hasAgreedToTerms(): noreturn
{
throw new \Exception('Kids cannot legally agree to terms');
}
}
While that may be technically correct from a type theory perspective (my type theory isn't
strong enough to say either way), I don't feel like that obeys Liskov. If I have an array of
Person objects, and I iterate them to check if they've all agreed to terms, I expect the return
value to be a *usable* type in the Person interface or a subtype of it *that I can still use*. I
cannot use Kid's return type, because it's by definition non-existent.
That feels like a bad time bomb.
Other than that concern, I'm fine with the spec. I would marginally prefer "never"
over "noreturn", but not enough to vote against it just for that.
--Larry Garfield