Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113640
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-ID: <96b4b678-6605-4b9b-a493-e4c9adfc11d5@www.fastmail.com>
In-Reply-To: 
 <CAKuGYLRjOHWnX24kCVpTUV5DwdVTwcSkakZkZiAmF9YhpGDpVw@mail.gmail.com>
References: 
 <CAKuGYLRjOHWnX24kCVpTUV5DwdVTwcSkakZkZiAmF9YhpGDpVw@mail.gmail.com>
Date: Sat, 20 Mar 2021 10:35:00 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] noreturn type
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Mar 10, 2021, at 12:06 PM, Matthew Brown wrote:
> Hey,
>=20
> Ond=C5=99ej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>=20
> 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.
>=20
> Thanks,
>=20
> Matt & Ond=C5=99ej

My main concern is around the covariance of inheritance.  The example gi=
ven:

abstract class Person
{
    abstract public function hasAgreedToTerms(): bool;
}
=20
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 t=
hat obeys Liskov.  If I have an array of Person objects, and I iterate t=
hem to check if they've all agreed to terms, I expect the return value t=
o 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 definit=
ion non-existent. =20

That feels like a bad time bomb.

Other than that concern, I'm fine with the spec.  I would marginally pre=
fer "never" over "noreturn", but not enough to vote against it just for =
that.

--Larry Garfield