> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matt...@anandabits.com
>> <mailto:matt...@anandabits.com>> wrote:
>> One related topic that isn’t discussed is type errors. Many third party
>> libraries use a Result type with typed errors. Moving to an async / await
>> model without also introducing typed errors into Swift would require giving
>> up something that is highly valued by many Swift developers. Maybe Swift 5
>> is the right time to tackle typed errors as well. I would be happy to help
>> with design and drafting a proposal but would need collaborators on the
>> implementation side.
>
> Typed throws is something we need to settle one way or the other, and I agree
> it would be nice to do that in the Swift 5 cycle.
My view of this is the opposite of Matthew's—the canonical examples of things
for which untyped errors are the "right thing" due to unbounded failure modes,
such as file IO, IPC, network communication, etc. are almost all things you
also want to be 'async', so I don't think async makes typed 'throws' any more
urgent to consider. As we've discussed in person, I feel like there's a strong
argument to be made that 'async' should always imply untyped 'throws'.
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
