<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br>Hi Chris,<div><br></div><div>I love what I’ve read so far. I just have one curiosity from my cursory look over the proposal.</div><div><br></div><div>It seems that in transitioning API to an Async Await system, the completion handler’s type becomes the return type. How would you handle bridging in Foundation API that already has a return type, eg URLSession returns you data tasks, and then fires a completion handler. Perhaps I missed something. I’m sure you could always form a tuple as well, just curious the thoughts on that.</div><div><br></div><div>Thanks,</div><div><br></div><div><div>Rod</div><div><br>On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 3:24 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Anyway, here is the document, I hope it is useful, and I’d love to hear comments and suggestions for improvement:<br class=""><a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782" class="">https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782</a><br class=""></div></div></blockquote></div><br class=""><div class="">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:</div><div class=""><div class=""><a href="https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619" class="">https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619</a></div><div class=""><br class=""></div><div class="">and I have a PR with the first half of the implementation here:</div><div class=""><a href="https://github.com/apple/swift/pull/11501" class="">https://github.com/apple/swift/pull/11501</a></div><div class=""><br class=""></div></div><div class="">The piece that is missing is code generation support.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>