(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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
