On Thu, Aug 17, 2017 at 5:25 PM, Chris Lattner via swift-evolution < [email protected]> wrote:
> > On Aug 17, 2017, at 3:24 PM, Chris Lattner <[email protected]> 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 :)
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
