On Wed, 31 Mar 2021 at 14:41, Ilija Tovilo <tovilo.il...@gmail.com> wrote:
>
> Hi internals
>
> On Wed, Mar 31, 2021 at 2:14 PM Andreas Hennings <andr...@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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
