Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113878
MIME-Version: 1.0
References: <CAKuGYLTStzEuOmhGKDdNdWP2iX_--mqV17jub0LgVPs+O6Bd+g@mail.gmail.com>
 <CAPrKfG7W7H27mqXdTzedzeCtoEEKif_T-HNinBhvyKrCVTxCqg@mail.gmail.com> <CAB-BujZO--x6QJGaKvPr1j3i+CEGxNQdOqLY7WpThWCCyBOzvA@mail.gmail.com>
In-Reply-To: <CAB-BujZO--x6QJGaKvPr1j3i+CEGxNQdOqLY7WpThWCCyBOzvA@mail.gmail.com>
Date: Wed, 31 Mar 2021 14:41:05 +0200
Message-ID: <CAPyj-LCmUVFgEHDC1C_2XLwvkkwUhsrEsYA4AdpGH6GVNF=ocQ@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] noreturn type
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi internals

On Wed, Mar 31, 2021 at 2:14 PM Andreas Hennings <andreas@dqxtech.net> wrote:
>
> Also check my comment in the other thread:
> If in the future we want a "bottom type" that also works for parameters
> (generics or abstract methods), should we create a new keyword, or should
> we attempt to find a keyword now that works for all cases?
> Neither "never" nor "noreturn" seems suitable for use in parameters, but
> "nothing" would be.

While slightly misleading, noreturn absolutely could work as a
parameter type, it's just not part of this RFC. I don't see why
nothing would be more suitable than never.

I do think noreturn/never in parameter types could potentially be
useful as it would serve as static analysis information and a runtime
check at the same time.

https://stackoverflow.com/a/39419171/1320374

```
function shouldNotHappen(never $never): void {}

/** @param 1|2|3 $foo */
function foo($foo) {
    switch ($foo) {
        case 1: return 'One';
        case 2: return 'Two';
    }

    // Static analyzer can understand this value is not never but 3
    // Throws a type error at runtime when reached as nothing can satisfy never
    shouldNotHappen($foo);
}
```

Although it's worth noting that match doesn't have that problem as it
throws implicitly on unhandled values. So maybe we should focus our
efforts on making match usable with code blocks instead of just
expressions.

Ilija