<div dir="ltr">On Thu, Aug 17, 2017 at 5:25 PM, Chris Lattner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Aug 17, 2017, at 3:24 PM, Chris Lattner &lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt; wrote:</div><br class="m_-3381954310706349815Apple-interchange-newline"><div><div>Hi all,<br><br>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><br>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><br>Anyway, here is the document, I hope it is useful, and I’d love to hear comments and suggestions for improvement:<br><a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782" target="_blank">https://gist.github.com/<wbr>lattner/<wbr>31ed37682ef1576b16bca1432ea9f7<wbr>82</a><br></div></div></blockquote></div><br></span><div>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><div><a href="https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619" target="_blank">https://gist.github.com/<wbr>lattner/<wbr>429b9070918248274f25b714dcfc76<wbr>19</a></div><div><br></div><div>and I have a PR with the first half of the implementation here:</div><div><a href="https://github.com/apple/swift/pull/11501" target="_blank">https://github.com/apple/<wbr>swift/pull/11501</a></div><div><br></div></div><div>The piece that is missing is code generation support.</div></div></blockquote><div><br></div><div>Hi Chris et al,</div><div><br></div><div>This is definitely a great initial model.</div><div><br></div><div>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 &quot;probably the right set of tradeoffs&quot;--async, throws, async(nonthrowing)?</div><div><br></div><div>Naively, to me, the observation that in your introduction you&#39;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.</div><div><br></div><div>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 :)</div><div><br></div><div><br></div></div></div></div>