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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
