[swift-evolution] Type-annotated throws

[Bouke Haarsma]

On 2016-08-26 15:39:05 +0000, Félix Cloutier via swift-evolution said:

> Hi all,
> 
> Currently, a function that throws is assumed to throw anything. There 
> was a proposal draft last December to restrict that. The general idea 
> was that you'd write, for instance:
> 
> 
> enum Foo: ErrorProtocol {
>     case bar
>     case baz
> }
> 
> func frob() throws Foo {
>     throw Foo.bar // throw .bar?
> }
> 
> If you `catch Foo` (or every case of Foo), now that the compiler can 
> verify that your catch is exhaustive, you no longer have to have a 
> catch-all block at the end of the sequence.
> 
> This impacts the metadata format and has implications on resilience, 
> which leads me to believe that the discussion could qualify for the 
> phase 1 of Swift 4. If this is the case, I'd be interested in pulling 
> out the old discussions and seeing where we left that at.
> Félix 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


Hi,

Shouldn't the compiler be able to infer the types thrown, and thus 
whether all types have been thrown? The general idea being that the 
following would be valid:

enum Foo: Error {
    case bar
    case baz
}

func hello() throws { // inferred to throw only "Foo.bar"
    throw Foo.bar
}

func world() throws { // inferred to throw only "Foo.baz"
    throw Foo.baz
}

func galaxy() throws { // inferred to throw only "Foo.baz"
    do {
        try hello()
    } catch Foo.bar {
        // ...
    }
    // catch is exhaustive, no catch-all clause needed

    try world()
}

func universe() { // all errors are handled, no 'throws' declaration needed
    do {
        try galaxy()
    } catch Foo.baz {
        // ..
    }
    // catch is exhaustive, no catch-all clause needed
}

Now for clarity one could add the type information as per your 
proposal, but wouldn't be necessary as the compiler would infer it 
itself.

Either way a +1 from me, as the current model forces one to catch-all 
errors, even the ones you did not expect to be thrown. Thus potentially 
hiding programming errors.

- Bouke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160828/dbdb989a/attachment.html>