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

Pyry Jahkola pyry.jahkola at iki.fi
Mon Jun 6 15:02:34 CDT 2016

> On 06 Jun 2016, at 22:40, Michael Peternell via swift-evolution <swift-evolution at swift.org> wrote:
> 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!

This isn't my understanding of the idea. My understanding is that instead of a generic function, you'd write `error` as:

    func error(_ msg: String = "") -> Never {
        fatalError("bottom: \(msg)")
        // or equivalently, since fatalError() also returns Never:
        //return fatalError("bottom: \(msg)")

And because `Never` is a real bottom type (this is probably the extra compiler support needed that Chris Lattner referred to), you can use this function in any type context, meaning that it behaves as if it's of type `∀x. String → x`:

    // Example 1:
    func someImplementationDetail(input: Int) -> [String] {
        // ...
        return error("unimplemented for now")

    // Example 2:
    var ints: [Int] = []

    // Example 3:
    let e: Either<String, String> = ...
    let s: String = e.left ?? e.right ?? error("impossible")

I would even consider specifying that every empty enum type behaves like this, and that `Never` was just the default you should probably use, defined in the stdlib as:

    /// The bottom type, or return type of functions that do not return.
    /// This enum is intentionally empty.
    enum Never {}

In other words in my imagination, there would be no magic in the type `Never` per se, but in the treatment of empty enums in general.

— Pyry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160606/2d5e3bc1/attachment.html>

More information about the swift-evolution mailing list