> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
