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

Brent Royal-Gordon brent at architechies.com
Mon Jun 6 19:24:52 CDT 2016


> E.g. with the proposal, the following function:
> 
> @noreturn func error<T>(msg: String = "") -> T {
>    fatalError("bottom: \(msg)")
> }
> 
> has to be written as
> 
> func error<T>(msg: String = "") -> T {
>    fatalError("bottom: \(msg)")
> }
> 
> It still returns bottom, but there is no way to say so in the declaration. The proposal just made the language less expressive!

Can you not see how strange this code is? You're saying the function cannot return, and then providing a return type. What does that even mean?

And Pyry is also correct: `func error(msg: String = "") -> Never` gives you the "assign to anything" semantics you're looking for anyway. What it does *not* allow you to do is something like:

	@noreturn func error(msg: String = "") -> ErrorProtocol

But again, what is that supposed to mean? If you're planning to fill in the implementation later and are just temporarily `fatalError()ing`, why are you marking it `@noreturn`, undermining its use as a stub? And if you intend it to stay `@noreturn`, why are you specifying a return type it will never actually return?

If you're *not* returning an unconstrained generic type—a use case `Never`'s subtype-of-all-types nature intrinsically covers—what *is* the use case where you need to specify both a return type *and* that the function never returns *in* the function's signature?

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list