<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 4:56 PM, Rod Brown &lt;<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>&gt; 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><br class=""></div><div>Ah, e.g. this one:</div><div><br class=""></div><div><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="color: #000000" class=""> </span>URLSession<span style="color: #000000" 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="">&nbsp; &nbsp; <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="">&nbsp;&nbsp; &nbsp; * data task convenience methods.&nbsp; 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="">&nbsp;&nbsp; &nbsp; * 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="">&nbsp;&nbsp; &nbsp; * 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="">&nbsp;&nbsp; &nbsp; * data.&nbsp; Errors will be returned in the NSURLErrorDomain,&nbsp;</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="">&nbsp;&nbsp; &nbsp; * see &lt;Foundation/NSURLError.h&gt;.&nbsp; 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="">&nbsp;&nbsp; &nbsp; * 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="">&nbsp;&nbsp; &nbsp; */</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class="">&nbsp; &nbsp; <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>?) -&gt; <span style="color: #703daa" class="">Swift</span>.<span style="color: #703daa" class="">Void</span>) -&gt; <span style="color: #703daa" class="">URLSessionDataTask</span></div><div class=""><span style="color: #703daa" class="">}</span></div></div><div><br class=""></div><div>Returning a tuple is an option, but probably wouldn’t provide the right semantics. &nbsp;The&nbsp;URLSessionDataTask is supposed to be available immediately, not just when the completion handler is called. &nbsp;The most conservative thing to do is to not have the importer change these. &nbsp;If they should have async semantics, they can be manually handled with an overlay.</div><div><br class=""></div><div>In any case, I wasn’t aware of those APIs, thanks for pointing them out. &nbsp;I added a mention of this to the proposal!</div><div><br class=""></div><div>-Chris</div><div><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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>&gt; 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. &nbsp;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. &nbsp;Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete. &nbsp;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). &nbsp;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=""></body></html>