> On 7 Jun 2016, at 17:47, Brent Royal-Gordon <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
