Hi Chris, This is fantastic! Thanks for taking the time to write down your thoughts. It’s exciting to get a glimpse at the (possible) road ahead.
In the manifesto you talk about restrictions on passing functions across an actor message. You didn’t discuss pure functions, presumably because Swift doesn’t have them yet. I imagine that if (hopefully when) Swift has compiler support for verifying pure functions these would also be safe to pass across an actor message. Is that correct? The async / await proposal looks very nice. One minor syntax question - did you consider `async func` instead of placing `async` in the same syntactic location as `throws`? I can see arguments for both locations and am curious if you and Joe had any discussion about this. 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. Matthew > On Aug 17, 2017, at 5:25 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clatt...@nondot.org >> <mailto:clatt...@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 >> <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 > <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. > > -Chris > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
