# [VOTE] noreturn type

- Thread: https://externals.io/message/113869
- Original archive: https://news-web.php.net/php.internals/113869
- Started by Matthew Brown on 2021-03-30T15:06:25+00:00
- Messages: 30
- RFC: noreturn type (Implemented (PHP 8.1)) — https://externals.io/rfc/noreturn_type.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/113869.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #113869 — Matthew Brown — 2021-03-30T15:06:25+00:00

URL: https://externals.io/message/113869#113869

Hey everyone!

The vote for adding noreturn is now open:

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

Voting will run through April 13th

Best wishes,

Matt and Ondrej

---

## #113873 — Theodore Brown — 2021-03-30T16:55:44+00:00

URL: https://externals.io/message/113869#113873 · In reply to: #113869

> 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.

Kind regards,
Theodore

---

## #113875 — Matthew Brown — 2021-03-30T22:24:37+00:00

URL: https://externals.io/message/113869#113875 · In reply to: #113873

> On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown <matthewmatthew@gmail.com>
> wrote:
>
> > […]
>
> 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.
>
> Kind regards,
> Theodore


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".

---

## #113876 — Peter Stalman — 2021-03-31T03:34:53+00:00

URL: https://externals.io/message/113869#113876 · In reply to: #113869

Aw, my `terminus` suggestion didn't make it. ☹️

Thanks,
Peter

---

## #113877 — Andreas Hennings — 2021-03-31T12:14:21+00:00

URL: https://externals.io/message/113869#113877 · In reply to: #113876

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.

-- Andreas



> Aw, my `terminus` suggestion didn't make it. ☹️
>
> Thanks,
> Peter

---

## #113878 — Ilija Tovilo — 2021-03-31T12:41:05+00:00

URL: https://externals.io/message/113869#113878 · In reply to: #113877

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

---

## #113879 — Andreas Hennings — 2021-03-31T13:02:05+00:00

URL: https://externals.io/message/113869#113879 · In reply to: #113878

>
> Hi internals
>
> 
> > […]
>
> 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
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #113880 — Theodore Brown — 2021-03-31T13:30:43+00:00

URL: https://externals.io/message/113869#113880 · In reply to: #113875

> 
> 
> > […]
> 
> 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

---

## #113881 — Matthew Brown — 2021-03-31T13:53:06+00:00

URL: https://externals.io/message/113869#113881 · In reply to: #113880

> On Tue, Mar 30, 2021 at 5:24 PM Matthew Brown <matthewmatthew@gmail.com>
> wrote:
>
> > […]
> wrote:
> > […]
> matthewmatthew@gmail.com> wrote:
> > […]
> https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type
> ).
> > […]
>
> 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


I've removed that sentence.

Opinions evolved — I wrote the RFC with the original language favouring
"noreturn", Ondrej edited it, adding more arguments for "never". Since we
published the RFC some in the community have validated his arguments, and I
think Ondrej's opinion has become stronger as a result (and mine has become
weaker). Whatever happens, I think we care much more that this passes than
what it's exactly called.

Best wishes,

Matt

---

## #113896 — Benjamin Eberlei — 2021-04-01T08:56:42+00:00

URL: https://externals.io/message/113869#113896 · In reply to: #113869

On Tue, Mar 30, 2021 at 5:07 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
>
> Best wishes,
>
> Matt and Ondrej
>

I voted no, because i think this should at the maximum be 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.

---

## #113897 — Sebastian Bergmann — 2021-04-01T08:58:56+00:00

URL: https://externals.io/message/113869#113897 · In reply to: #113896

Am 01.04.2021 um 10:56 schrieb Benjamin Eberlei:
> I voted no, because i think this should at the maximum be 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.

Following Benjamin's argument, I have changed my vote to no.

---

## #113904 — Matthew Brown — 2021-04-01T12:58:29+00:00

URL: https://externals.io/message/113869#113904 · In reply to: #113896

> 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.

"Noreturn"/"never" is also recognised as a type by the wider programming
language community. It can be checked at both compile-time and run-time by
the engine, as detailed in the RFC. Indeed, _no other return type makes
sense in the context_.

The type definitely felt awkward when I first started using it in
docblocks, but after a while it started to make intuitive sense.

Best wishes,

Matt/Ondrej

---

## #113908 — Andreas Leathley — 2021-04-01T13:56:04+00:00

URL: https://externals.io/message/113869#113908 · In reply to: #113896

> 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:

```php
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:

```php
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. Using attributes has the disadvantage
of not making the intent clear:

```php
#[\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.

---

## #113912 — Benjamin Eberlei — 2021-04-01T15:07:15+00:00

URL: https://externals.io/message/113869#113912 · In reply to: #113908

> 
> > […]
> enough
> > […]
>
> 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:
>
> ```php
> 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:
>
> ```php
> 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.

```php
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:
>

> ```php
> #[\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

---

## #113916 — Andreas Leathley — 2021-04-01T15:51:29+00:00

URL: https://externals.io/message/113869#113916 · In reply to: #113912

> 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.
>
> ```php
> 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.

Throwing an exception immediately is an alternative, but this only works
if that is the absolute only thing the method does, and even then it
leads to a lot of repetition (if you have many controllers) with very
specific code shared in each controller. Making the identical behavior
between controllers explicit by a shared "notFound" method seems better
coding to me, and it has the advantage of being very readable and
something you can easily recognize between different controllers - you
look it up once and know what it does. If you throw exceptions in each
controller, you might wonder if this is the exact same exception as
another one in another controller. Often you might also want to change
the behavior at some point - for example log the event before throwing
the exception, or handling notFound entirely different. noreturn/never
gives you the flexibility to refactor "throw NotFoundException();" into
a method while keeping the promise that the code flow will not continue.

Abstracting away something like a redirect, an authorization problem or
a 404 also seems an improvement to me (compared to "throw
NotFoundException();") because you write and test that logic once, and
then reuse it in different places. Like with other parts of the type
system in PHP noreturn/never just gives you stronger guarantees and more
information about what a function/method is ought to do and how it behaves.

---

## #113920 — Bruce Weirdan — 2021-04-01T17:24:35+00:00

URL: https://externals.io/message/113869#113920 · In reply to: #113912

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

Since `throw` is an expression (since PHP 8.0,
https://wiki.php.net/rfc/throw_expression), it must have a type for its
result,
as any expression has a type. And it's result is exactly `noreturn` (or
`never`, as this option seems to be preferred
judging by current vote results), because `throw` never returns.

It's quite natural to extend that to function calls that never return as
well. And then it makes sense to declare that type
as a part of function signature like you can do with other types.

-- 
  Best regards,
      Bruce Weirdan                                     mailto:
weirdan@gmail.com

---

## #113922 — ondrej@mirtes.cz — 2021-04-01T19:03:03+00:00

URL: https://externals.io/message/113869#113922 · In reply to: #113920

> Since `throw` is an expression (since PHP 8.0,
> https://wiki.php.net/rfc/throw_expression), it must have a type for its
> result,
> as any expression has a type. And it's result is exactly `noreturn` (or
> `never`, as this option seems to be preferred
> judging by current vote results), because `throw` never returns.
>
> It's quite natural to extend that to function calls that never return as
> well. And then it makes sense to declare that type
> as a part of function signature like you can do with other types.
>
> --
>  Best regards,
>      Bruce Weirdan                                     mailto:
> weirdan@gmail.com
>

Yes, this works very well in the typesystem. For example if we define the
type of the match expression as a union of all its arms, then the arm that
always throws or contains `exit()` has the noreturn/never type, which is
thrown away in a union (int|string|never can be normalized to int|string).

---

## #113923 — Levi Morrison via internals — 2021-04-01T19:03:10+00:00

URL: https://externals.io/message/113869#113923 · In reply to: #113904

>
> 
>
> > […]
>
> 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][1] 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][2], 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.

  [1]: https://wiki.php.net/rfc/void_return_type#why_call_it_void_and_not_null
  [2]: https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages

---

## #113927 — Aaron Piotrowski — 2021-04-02T01:13:52+00:00

URL: https://externals.io/message/113869#113927 · In reply to: #113923

> 
> 
> 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.
> 

You make an excellent point Levi. I initially chose `noreturn` simply because I was familiar with the name from C and didn't have a strong opinion. However, I agree that `noreturn` is a poor choice for reuse as a bottom type, so I changed my vote to `never`.

Cheers,
Aaron Piotrowski

---

## #113930 — Kamil Tekiela — 2021-04-02T20:13:22+00:00

URL: https://externals.io/message/113869#113930 · In reply to: #113927

I am still not comfortable with the error message "Nothing was expected to
be returned" which is very confusing and I would change it to "was expected
to throw or exit" or "was expected to never return".
I went with "never" because it just reads better: "Function abc returns
never" instead of "Function abc returns noreturn". If "never" wins then the
other error message "A noreturn function must not return" must also be
changed. Maybe "The function must never return"

---

## #113935 — Benjamin Eberlei — 2021-04-03T15:30:24+00:00

URL: https://externals.io/message/113869#113935 · In reply to: #113927

>
> > […]
> internals@lists.php.net> wrote:
> > […]
>
> You make an excellent point Levi. I initially chose `noreturn` simply
> because I was familiar with the name from C and didn't have a strong
> opinion. However, I agree that `noreturn` is a poor choice for reuse as a
> bottom type, so I changed my vote to `never`.
>

i voted against this proposal, but changed my choice of "noreturn" to
"never", because it would ultimately be slightly less bad to have this name
for use as a bottom type. The name "never" is still unfortunate, because it
transmits "behavior" of being used in the context of a function, a better
name might have been "nothing" as Levi suggests.

But I again get to the point of the problem with this RFC due to naming.
"never" is actually combining "nothing" type with "noreturn" flag, so for
me the most consistent way would have been "public noreturn function foo():
nothing"

Its said that composition is better than inheritance, so combining two
behaviors into one keyword will be limiting in the future, if we think of
other function flags that should compose with "never".


> Cheers,
> Aaron Piotrowski

---

## #113936 — Rowan Tommins — 2021-04-03T15:54:52+00:00

URL: https://externals.io/message/113869#113936 · In reply to: #113935

> But I again get to the point of the problem with this RFC due to naming.
> "never" is actually combining "nothing" type with "noreturn" flag, so for
> me the most consistent way would have been "public noreturn function foo():
> nothing"


I'm not sure how the flag and return type could ever be used separately. 
Are you suggesting that we should allow all 3 of these:

- public noreturn function foo(): nothing
- public noreturn function foo(): int
- public function foo(): nothing

How would any tool treat these differently?

Regards,

-- 
Rowan Tommins
[IMSoP]

---

## #113937 — Benjamin Eberlei — 2021-04-03T16:30:09+00:00

URL: https://externals.io/message/113869#113937 · In reply to: #113935

>
>
> 
>
> > […]
>
> i voted against this proposal, but changed my choice of "noreturn" to
> "never", because it would ultimately be slightly less bad to have this name
> for use as a bottom type. The name "never" is still unfortunate, because it
> transmits "behavior" of being used in the context of a function, a better
> name might have been "nothing" as Levi suggests.
>
> But I again get to the point of the problem with this RFC due to naming.
> "never" is actually combining "nothing" type with "noreturn" flag, so for
> me the most consistent way would have been "public noreturn function foo():
> nothing"
>

Sorry, i should have been more detailed/precise before:

Why i think "never" is not a great solution, if you have the same example
that TypeScript uses to explain their "never":

if (is_string($value) && is_int($value)) {
   // inside here $value is_type == "never"
}

The naming "never" here makes no sense, because from a theoretical
perspective reasoning about the type of $value it is nothing and only the
block of code is "never reached".

I suppose PHPStan and Psalm are eager to reuse the new type name for this
kind of type interference, same as TypeScript does. The name is sub
optiomal outside the context of a return type.

So lets say we seperate the two behaviors of "never" into "nothing +
noreturn".

public noreturn function foo(): nothing {
    `exit()`;
}

But adding a new keyword "noreturn" would not be necessary, it could just
be an Attribute as i said in my first e-mail explaining my no-vote:

#[NoReturn] // sets a function flag modifying the void behavior
public function foo(): nothing {
    return; // throws if it reaches this point
}

This would be closer to what Psalm and PHP-Stan use at the moment if we
replace nothing with void.

The problem is that "void" is already not perfect, since the callside
doesn't care about "return null" with no return type vs "return" + void
return type.

If we had "nothing" and "null" instead of "void", and we'd say like PHP
works, "return;" actually means "return null;", then:

function foo(): nothing {
    return; // Error: cannot return null from a function that returns
nothing.
}
function bar(): null {
    return;
    // or return null;
}

This would more consistently tie into union types where |null is allowed,
however on its own it is not: "foo() : null => error".

As Levi said, this noreturn/never just perpetuates/amplifies the existing
void mistake and feels off, given that other recent changes to PHP have
been more bold, towards removing inconsistencies.


> Its said that composition is better than inheritance, so combining two
> behaviors into one keyword will be limiting in the future, if we think of
> other function flags that should compose with "never".
>
>
> > […]

---

## #113940 — Peter Bowyer — 2021-04-03T19:26:34+00:00

URL: https://externals.io/message/113869#113940 · In reply to: #113937

> The problem is that "void" is already not perfect, since the callside
> doesn't care about "return null" with no return type vs "return" + void
> return type.
>
> If we had "nothing" and "null" instead of "void", and we'd say like PHP
> works, "return;" actually means "return null;", then:
>
> function foo(): nothing {
>     return; // Error: cannot return null from a function that returns
> nothing.
> }
> function bar(): null {
>     return;
>     // or return null;
> }
>
> This would more consistently tie into union types where |null is allowed,
> however on its own it is not: "foo() : null => error".
>
> As Levi said, this noreturn/never just perpetuates/amplifies the existing
> void mistake and feels off, given that other recent changes to PHP have
> been more bold, towards removing inconsistencies.
>

This and Levi's email make compelling arguments and I would like to see
this adopted. I have changed my vote to "No".

Peter

---

## #113939 — Andreas Leathley — 2021-04-03T19:27:24+00:00

URL: https://externals.io/message/113869#113939 · In reply to: #113937

> if (is_string($value) && is_int($value)) {
>     // inside here $value is_type == "never"
> }
>
> The naming "never" here makes no sense, because from a theoretical
> perspective reasoning about the type of $value it is nothing and only the
> block of code is "never reached".
>
> I suppose PHPStan and Psalm are eager to reuse the new type name for this
> kind of type interference, same as TypeScript does. The name is sub
> optiomal outside the context of a return type.
>
I read through all the Typescript and Hack explanations/examples of
"never" and "nothing", and to me "never" seems clearer, which just shows
how different opinions can be. I would not like "nothing" because it
seems so similar to "void" and "null". "This function returns nothing"
would inevitably lead to the question what that actually means. "This
function returns never" is a reasonably clear description. "This
variable at this point is never" or "This variable at this point is
nothing" are both not clear without context, although never implies this
should not happen (or cannot happen) and could be interpreted as "This
variable at this point is never anything", which in general would be
clearer to me (not being familiar with either before this proposal).

 From a practical perspective, I think the proposal is about the return
type because this has a clear use case in code today. Your $value
example would lead to the Psalm/PHPStan errors of "Type does not contain
type" (Psalm) or "Result of && is always false" (PHPStan), I don't think
there currently is much use to determine a type of never in these cases.
But that might be something Matt/Ondrej can answer a lot better than me.

I initially preferred "noreturn", but now prefer "never". "noreturn" is
more self-explanatory, but "never" seems more apt and versatile, while
still being quite clear.

---

Next page: https://externals.io/message/113869.md?page=2