[swift-evolution] [Concurrency] async/await + actors

[Chris Lattner]

On Aug 17, 2017, at 5:51 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Oh, also, one relatively short term piece of this model is a proposal for adding an async/await model to Swift (in the form of general coroutine support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 <https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619>
> 
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501 <https://github.com/apple/swift/pull/11501>
> 
> The piece that is missing is code generation support.
> 
> Hi Chris et al,
> 
> This is definitely a great initial model.
> 
> To clarify, are the authors proponents of the syntax shown in the body of the draft--async, throws, async throws--or of the alternative design listed below that is "probably the right set of tradeoffs"--async, throws, async(nonthrowing)?

I believe that Joe is in favor of making async imply throws, but I’ll let him speak to why.

I’m weakly in favor of it, because I believe it will lead to a simpler system in practice.  It seems that many async operations should also throw, so a design where async implies throw seems like it would skew to the right thing.  Not just on the declaration side, but also on the marker side, because instead of “try await” everywhere, we could make await imply try.  Another reason is that this would lead to a simpler actor model, where we’d probably just bake the “reliability” stuff directly into the base actor model, since all the async APIs can throw already.

That said, I don’t feel like I have enough data to have a strong opinion on it.  The missing link for me is exactly how pervasive the non-throwing cocoa completion handlers are.  If it turns out that people would have to confront "async(nonthrowing)” in practice (as opposed to being an obscure corner that the compiler implementers have to care about) then it is probably the wrong design.

> Naively, to me, the observation that in your introduction you've separated `async` and `throws` suggests that keeping the two orthogonal to each other is the more teachable design. I appreciate how there is an intimate connection between `async` and `throws`, but it seems to me that `async(nonthrowing)` is a highly unintuitive result--_especially_ since the rationale for not outright making `async` a subtype of `throws` is that asynchronous non-throwing functions are a key Cocoa idiom.

Agreed.

> Other than that, I would hope that the primitive functions `beginAsync`, etc., are indeed exposed outside the standard library; agree that their names could use some light bikeshedding :)

+1!

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/3016a7a4/attachment.html>