Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113471
MIME-Version: 1.0
References: <CAKuGYLRjOHWnX24kCVpTUV5DwdVTwcSkakZkZiAmF9YhpGDpVw@mail.gmail.com>
 <e397c220-13cb-6055-3e1e-3aaf3ee18ae9@alec.pl> <F06253BB-9B2C-49DC-B382-A222506E2F26@benramsey.com>
 <a3360baf-0dfa-1170-6303-0f7fc365ba41@alec.pl>
In-Reply-To: <a3360baf-0dfa-1170-6303-0f7fc365ba41@alec.pl>
Date: Thu, 11 Mar 2021 10:59:49 +0100
Message-ID: <CADyq6sJTCYRrevXRV=indHa02HA-ZLiDTHafdHKE=dViF0+txw@mail.gmail.com>
To: Aleksander Machniak <alec@alec.pl>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c40f0805bd3fd8cf"
Subject: Re: [PHP-DEV] [RFC] noreturn type
From: ocramius@gmail.com (Marco Pivetta)

--000000000000c40f0805bd3fd8cf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Aleksander,

On Thu, Mar 11, 2021 at 8:25 AM Aleksander Machniak <alec@alec.pl> wrote:

> On 10.03.2021 20:28, Ben Ramsey wrote:
> >> I don't like that type covariance would be allowed. Why such an
> >> exception to the rules?
> >
> > It=E2=80=99s not an exception. Returns are covariant. Parameters are
> > contravariant. Since `noreturn` is a subtype of all other types, it
> > behaves as expected.
>
> I see it's a subtype, I don't get why. Wouldn't it be better to be a
> separate type so return type covariance is not allowed (as it is with
> void)? Was it a design decision or a side product of the implementation?
>

`noreturn` is what's called the "bottom type", and it's a subtype of all
types.
It can sound counter-intuitive, but it is true that all methods in a
subclass can be re-implemented with the bottom type as their return type
(instead of their original one), and the system is still sound from a type
perspective.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--000000000000c40f0805bd3fd8cf--