<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 4:56 PM, Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><br class="">Hi Chris,<div class=""><br class=""></div><div class="">I love what I’ve read so far. I just have one curiosity from my cursory look over the proposal.</div><div class=""><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">Ah, e.g. this one:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(112, 61, 170); background-color: rgb(255, 255, 255);" class=""><span style="color: #ba2da2" class="">extension</span><span style="" class=""> </span>URLSession<span style="" class=""> {</span></div><div style="margin: 0px; line-height: normal; background-color: rgb(255, 255, 255); min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""> <span style="color: #008400" class="">/*</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * data task convenience methods. These methods create tasks that</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * bypass the normal delegate calls for response and data delivery,</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * and provide a simple cancelable asynchronous interface to receiving</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * data. Errors will be returned in the NSURLErrorDomain, </div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * see <Foundation/NSURLError.h>. The delegate, if any, will still be</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> * called for authentication challenges.</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0); background-color: rgb(255, 255, 255);" class=""> */</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""> <span style="color: #ba2da2" class="">open</span> <span style="color: #ba2da2" class="">func</span> dataTask(with request: <span style="color: #703daa" class="">URLRequest</span>, completionHandler: <span style="color: #ba2da2" class="">@escaping</span> (<span style="color: #703daa" class="">Data</span>?, <span style="color: #703daa" class="">URLResponse</span>?, <span style="color: #703daa" class="">Error</span>?) -> <span style="color: #703daa" class="">Swift</span>.<span style="color: #703daa" class="">Void</span>) -> <span style="color: #703daa" class="">URLSessionDataTask</span></div><div class=""><span style="color: #703daa" class="">}</span></div></div><div class=""><br class=""></div><div class="">Returning a tuple is an option, but probably wouldn’t provide the right semantics. The URLSessionDataTask is supposed to be available immediately, not just when the completion handler is called. The most conservative thing to do is to not have the importer change these. If they should have async semantics, they can be manually handled with an overlay.</div><div class=""><br class=""></div><div class="">In any case, I wasn’t aware of those APIs, thanks for pointing them out. I added a mention of this to the proposal!</div></div></div></div></blockquote><div><br class=""></div>Arguably these could be converted to return both the formal return value and a future. That would be a rather heroic rule for automatic import, though.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class=""><div class="">Rod</div><div class=""><br class="">On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><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" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>