[swift-evolution] Type-annotated throws

[Rod Brown]

(resent for Swift Evolution)

I’m a big fan of this idea. Currently “throws” seems like a very limited API - you know it’s throwing out something, but you can only hope to guess what that is or create fallbacks. Definitely a big +1 from me. A fallback for compatibility could be “throws” assumes “throws Any” and can be a warning?

While I am not deeply familiar with the implications, I do like think your line of reasoning has merit, and think this makes sense for Phase 1 of Swift 4. 

- Rod


> On 27 Aug 2016, at 1:39 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160827/4ba2fecd/attachment.html>