[VOTE] noreturn type View as Markdown

Hey everyone!

The vote for adding noreturn is now open:

https://wiki.php.net/rfc/noreturn_type

Voting will run through April 13th

Hi Matt and Ondrej,

Thanks for your work on this RFC. I voted for never as the type name
because it's more amenable to future use cases like compile-time
exhaustiveness checks (example:
https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type).

As a bonus never is more concise, avoids mashing two words together,
and aligns with TypeScript, which I and many other PHP devs also use.

Awesome! The conciseness argument for "never" is already mentioned in
the RFC, as is TypeScript's use of the term.

Full disclosure (because neither of us is eligible to vote):
I slightly prefer "noreturn", and Ondrej strongly prefers "never".

Hi Matt,

I'm confused by this. If Ondrej strongly prefers never, why does the
RFC say "we believe noreturn is the best name for this type"?

It might be better to just remove this sentence, or else list your separate preferences.

Thanks,
Theodore

Hi internals

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

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable enough
to justify this change.

By this argument "void" should also be an attribute – there's no reason to
hint a value that's not being returned.

You'd write functions like

[\Void]
function foo() { ... }

But we don't do that, because the wider programming language community has
agreed that "void" is a type, and at compile-time PHP's engine can ensure
that "void" functions do not return a value.

For what it is worth, it does return a value null, which has a type.
Using "void" is outright wrong, a lie told because "we" voted it this
way. Few people seemed to care when I brought this up, but null makes
sense with union types, covariance, etc, which we now have. I'm still
slightly bitter about this, in case you cannot tell.

The void RFC said:

There's no precedent for it and the name doesn't seem to have been an issue until now.

This was disingenuous, as it disregards Swift and Rust, both of which
use a unit type; they just call it () instead of null. These languages
are held in high regard as far as mainstream programming languages go,
but instead we voted to repeat the mistakes of C and company. I
believe Python's PEP 484 for Type Hints was available at this time,
and it uses None when no value is explicitly returned just like PHP
does with null.

But, we decided to do it the wrong way a la C. Let's please not repeat
this mistake. For the record, in C this is an attribute (and
non-standard at that!), not a return type, so this is a particularly
apt comparison.

Please, let's accurately follow type theory and use a bottom type.
According to the data in Wikipedia, the most common names for the
bottom type are:

1. never, used by Elm and Typescript. Note that in Rust the bottom
   type is ! but spelled out in docs as "never".
2. nothing, used by Kotlin, Ceylon, and Scala.

I do not care which name is chosen, but if we are going to have this
sort of thing in the language, it ought to be a bottom type, not an
attribute.

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable
enough
to justify this change.

I already use @return no-return (supported by Psalm/PHPStan) in my code
now, to clarify the code flow, and for me it fits perfectly for return
types, as not returning is also a result of the function/method. Having
a return type of "int" or "string" (or even "void") seems misleading
when the method will never return anyway.

noreturn/never might not be useful in all code, but for some parts like
in a controller of a web application it makes handling redirects,
authorization or 404 errors much easier, clearer and less error-prone,
for example:

if (!isset($user)) {
   $this->notFound(); // this is a noreturn/never method
}

if (!$this->isGranted('adminPrivileges')) {
   $this->notAuthorized(); // this is a noreturn/never method
}

Adding noreturn/never on a language level would make sure calling
"$this->notAuthorized();" never continues code flow. This is often also
a security issue, as seen by an alternative way of handling the above
use cases:

if (!isset($user)) {
   $this->notFound();
   return;
}

if (!$this->isGranted('adminPrivileges')) {
   $this->notAuthorized();
   return;
}

If you forget a return, suddenly you have issues. So even though
noreturn/never is a niche language feature not everyone will use, it
does address a very real use case.

I don't know, you are arguing that you forgot a return, but you also did
not forget to add a never return type. You
could easily fix this by inlining the exception instead.

if (!isset($user)) {
   throw new NotFoundException();
}

Even when you insist on the function, it is a one liner that throws
immediately. Adding the never return type there isn't going to catch a
great many bugs.

Using attributes has the disadvantage
of not making the intent clear:

#[\NoReturn]
function notAuthorized(): string
{
   // Some code
}

Now you have a return type of string, but also the information that the
function will never return anyway. That is confusing, but will be
inevitable in some cases when implementing interfaces or an abstract
class. In my opinion, the string return type is wrong in this case and
can only mislead a developer.

--

To unsubscribe, visit: https://www.php.net/unsub.php