[swift-evolution] [Draft] Change @noreturn to unconstructible return type

Jeremy Pereira jeremy.j.pereira at googlemail.com
Wed Jun 8 04:17:18 CDT 2016

> On 7 Jun 2016, at 17:47, Brent Royal-Gordon <brent at architechies.com> wrote:
>> I disagree. We are discussing how to annotate a function in some way so that the compiler knows that the code following it will never be executed *and* so a human who reads the declaration knows that it does not return. “Never" is a poor choice for that. Never what? Never return? Never use this function? Never say never again? 
> "Never return". That's why it's in the return type slot, right after the `->`. If you read it out loud, you'll read "returns Never", which is exactly correct.

I would read it as “returns an object of type “Never” if I hadn’t been reading this thread. “Never" is a bad choice if all you want to do is indicate to a human that the function does not return. 

> NoReturn, on the other hand, does *not* read well in that slot: "returns NoReturn". Huh? I mean, I suppose you won't misunderstand it, but it makes no sense whatsoever *as a type name*.

Who cares? We want it to be as obvious as possible that the function does not return not that the construct reads like an English sentence.

>> If you want bottom types for other uses, give them their own appropriate and self documenting names. 
> The problem is, types flow through the type system. Use a NoReturn method with optional chaining, now you have an Optional<NoReturn>. flatMap over that Optional<NoReturn>, now you have a parameter of type NoReturn. What's a *parameter* of type NoReturn? You'd want it to be, say, a different bottom type named NoPass, but you can't—the type came from a NoReturn, and it's stuck being a NoReturn.

This is a method that *does not return*. The compiler should error if you try to use the “result” of a no return function. In fact, it should error if there is any more code after the method that can’t be reached by a path that avoids the call.

I think you have convinced me that the idea of indicating noreturn methods with a return type is pretty stupid.

> Never works pretty well—honestly, surprisingly well—in all of these contexts.

It might do logically and from the ivory tower purist point of view, but for a casual reader of the code who just wants to understand the API 

    @noreturn func foo()

is vastly superior to 

   func foo() -> Never

More information about the swift-evolution mailing list