[RFC] noreturn type

Hey Matthew, I have look at the implementation a few days ago, and was patiently waiting for the RFC. a huge +1 from me ( even tho i can't vote ), `noreturn` type would be a great addition to PHP type system. Regards, Saif. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, March 10, 2021 7:06 PM, Matthew Brown <matthewmatthew@gmail.com> wrote:

On 10/03/2021 18:06, Matthew Brown wrote:

Thanks for the proposal, I can certainly think of uses for it. I am however slightly confused by what exactly the implementation checks, and when. Is it actually looking for "exit" and "throw" statements? The text talks about exiting "explicitly or implicitly", but doesn't give any examples of how this works. For instance, is this code valid, and how does PHP know that it's valid? function my_exit(string $reason): noreturn {     exit("$reason\n"); } function canned_exit(): noreturn {    my_exit("The normal reason"); } The other thing I'd like to mention is that PHP's implementation of "void" consists mostly of checking that there is no return statement, so a separate keyword of "noreturn" may well cause confusion. I would personally prefer the name "never" for this reason. Regards,

On 10.03.2021 19:06, Matthew Brown wrote:

I don't like that type covariance would be allowed. Why such an exception to the rules?

Am 10.03.2021 um 19:06 schrieb Matthew Brown:

Thank you, Ondřej and Matt, for bringing this up. Makes sense to me, +1.

Hi Matt & Ondřej, One of the things that makes PHP different from other languages (and for better for a change) is that every function returns a value, even where there is no explicit return statement. This eliminates a large number of edge-cases in code like: function log_result(mixed $bar) {...} log_result($anyCallable()); is always valid in PHP, whereas in other languages similar code can either refuse to compile, or error out when run, or other things like 'undefined' variables. I.E. in other languages, there are three exit conditions: * no value returned * a value returned * function has no normal exit And so other languages need to indicate between 'void' and 'no return' But in PHP there are only two exit conditions*: * a value returned * function has no normal exit I (and others) brought this up during the void RFC: https://news-web.php.net/php.internals/88990 and said that null was the right choice over void, as it matches what the language actually does. That would have left void available to mean 'this function' does not exit normally. Unfortunately people in the community have started doing what I feared, and using void as 'no value is returned', which is not what the language actually _does_. I realise the above might be slightly discombobulating if, for example, some people had written large static code analyzers that had misinterpreted void like this. I think we should introduce null. But we shouldn't introduce 'noreturn' even if a large number have misunderstood what the behaviour of the language is. It might be appropriate for the other languages that are listed in the other language section, but it's not appropriate in PHP which is different to those languages. cheers Dan Ack * so the usage of null and void return types should be: function returns(): null { if (rand(0, 100) === 0) { throw new \Exception('Surprise!');} // intentionally no code } function never_returns(): void { if (rand(0, 100) === 0) { throw new \Exception('Surprise!');} while (1) {} } For both of them, there are exceptions to the declared return type, but otherwise 'returns' returns the value null, and 'never_returns' never returns a value.

Hi Matt & Ondřej, I wanted to give my +1 to this proposal. I was curious to see how fibers might interact with this declaration, since it is possible to create a fiber that can not return. So, I compiled your branch and gave it a try. ``` $fiber = new Fiber(function (): noreturn { while (true) { Fiber::suspend(\random_int(0, 100)); } }); $result = $fiber->start(); for ($i = 0; $result; ++$i) { echo $result, "\n"; $result = $fiber->resume(); } echo "Generated ", $i, " numbers before generating zero.\n"; ``` This short script works just as expected, cool! :-D Cheers, Aaron Piotrowski

On Wed, Mar 10, 2021 at 7:07 PM Matthew Brown <matthewmatthew@gmail.com> wrote:

Thanks for the proposal! I think this is a nice addition. Regards, Nikita

On Wed, Mar 10, 2021 at 7:07 PM Matthew Brown <matthewmatthew@gmail.com> wrote:

Is it allowed to declare a noreturn function that returns by reference? function &foo(): noreturn {} Regards, Nikita

On Wed, Mar 10, 2021, at 12:06 PM, Matthew Brown wrote:

My main concern is around the covariance of inheritance. The example given: abstract class Person { abstract public function hasAgreedToTerms(): bool; } class Kid extends Person { public function hasAgreedToTerms(): noreturn { throw new \Exception('Kids cannot legally agree to terms'); } } While that may be technically correct from a type theory perspective (my type theory isn't strong enough to say either way), I don't feel like that obeys Liskov. If I have an array of Person objects, and I iterate them to check if they've all agreed to terms, I expect the return value to be a *usable* type in the Person interface or a subtype of it *that I can still use*. I cannot use Kid's return type, because it's by definition non-existent. That feels like a bad time bomb. Other than that concern, I'm fine with the spec. I would marginally prefer "never" over "noreturn", but not enough to vote against it just for that. --Larry Garfield

Hi Matthew

Thanks for the RFC! I'm very much in support of it. Two small things: 1. Some magic methods like __toString currently require a specific return type (like string in that case). Since noreturn is a bottom type technically it should be possible to type hint those magic methods with noreturn. It's not a big issue if that's not possible, but it should be mentioned in the RFC. 2. noreturn is one of the few return types that would technically make sense for __construct (other than void). class Foo { public function __construct(): noreturn { throw new Exception(); } } new Foo(); bar(); // < Dead code Not sure this is worth supporting but I just wanted to mention it. Ilija