Wouldn’t switching from `async` to `async throws` be both a source and ABI break for libraries? If so, there is a library evolution argument to `async` also encompassing throws as a reasonable default. It's likely that the non-throwing-ness of many `async` operations is an artifact of the initial implementation rather than deliberate design. Using the more verbose `async(non-throwing)` (or even some other keyword `generator|yielding|…`) makes it a deliberate API decision rather than an accidental omission.
> On Aug 18, 2017, at 10:05 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
