Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113879
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> <CAPyj-LCmUVFgEHDC1C_2XLwvkkwUhsrEsYA4AdpGH6GVNF=ocQ@mail.gmail.com>
In-Reply-To: <CAPyj-LCmUVFgEHDC1C_2XLwvkkwUhsrEsYA4AdpGH6GVNF=ocQ@mail.gmail.com>
Date: Wed, 31 Mar 2021 15:02:05 +0200
Message-ID: <CAB-Bujb7uqTNL5R_eydaxv-A8+mhnJu8OfuVaghZZ22F9cFrLA@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] noreturn type
From: andreas@dqxtech.net (Andreas Hennings)

On Wed, 31 Mar 2021 at 14:41, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> 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.

Technically any keyword would be "suitable" in parameters.
But having "noreturn" as a parameter type would look weird.

I think we should decide now if the new keyword should be suitable as
a parameter type name in the future or not.

> I don't see why nothing would be more suitable than never.

For me "nothing" looks a bit more like a type name than "never".
But seeing in your link that this already exists in typescript, I can
live with "never" :)

To your example below:
For me the real use case would be formal interfaces or base classes.
Ofc this will become more relevant with generics, but can already be
useful now with reflection-based architectures.

interface FormalHarvester {
  function harvest(never $x);
}

interface GraintHarvester extends FormalHarvester {
  function harvest(Grain $x);
}

So, if we introduce the "never" keyword now as a return type, with
this future use case in mind, that seems to be fine for me.

>
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>