[swift-evolution] typed throws
milseman at apple.com
Fri Aug 18 13:01:10 CDT 2017
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 at swift.org> wrote:
>> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at 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'.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution