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

[Xiaodi Wu]

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:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>
>
> 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
>
> and I have a PR with the first half of the implementation here:
> 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)?

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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/7ec3754c/attachment.html>