[swift-evolution] [Concurrency] async/await + actors
xiaodi.wu at gmail.com
Thu Aug 17 19:51:46 CDT 2017
On Thu, Aug 17, 2017 at 5:25 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:
> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clattner at nondot.org> wrote:
> Hi all,
> As Ted mentioned in his email, it is great to finally kick off discussions
> for what concurrency should look like in Swift. This will surely be an
> epic multi-year journey, but it is more important to find the right design
> than to get there fast.
> I’ve been advocating for a specific model involving async/await and actors
> for many years now. Handwaving only goes so far, so some folks asked me to
> write them down to make the discussion more helpful and concrete. While I
> hope these ideas help push the discussion on concurrency forward, this
> isn’t in any way meant to cut off other directions: in fact I hope it helps
> give proponents of other designs a model to follow: a discussion giving
> extensive rationale, combined with the long term story arc to show that the
> features fit together.
> Anyway, here is the document, I hope it is useful, and I’d love to hear
> comments and suggestions for improvement:
> 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:
> and I have a PR with the first half of the implementation here:
> 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,
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.
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution