<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="">On Aug 17, 2017, at 5:51 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class=""><div class=""><div dir="ltr" class=""><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" 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" target="_blank" class="">https://gist.github.com/<wbr class="">lattner/<wbr class="">429b9070918248274f25b714dcfc76<wbr class="">19</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" target="_blank" class="">https://github.com/apple/<wbr class="">swift/pull/11501</a></div><div class=""><br class=""></div></div><div class="">The piece that is missing is code generation support.</div></div></blockquote><div class=""><br class=""></div><div class="">Hi Chris et al,</div><div class=""><br class=""></div><div class="">This is definitely a great initial model.</div><div class=""><br class=""></div><div class="">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 "probably the right set of tradeoffs"--async, throws, async(nonthrowing)?</div></div></div></div></div></blockquote><div><br class=""></div><div>I believe that Joe is in favor of making async imply throws, but I’ll let him speak to why.</div><div><br class=""></div><div>I’m weakly in favor of it, because I believe it will lead to a simpler system in practice. It seems that many async operations should also throw, so a design where async implies throw seems like it would skew to the right thing. Not just on the declaration side, but also on the marker side, because instead of “try await” everywhere, we could make await imply try. Another reason is that this would lead to a simpler actor model, where we’d probably just bake the “reliability” stuff directly into the base actor model, since all the async APIs can throw already.</div><div><br class=""></div><div>That said, I don’t feel like I have enough data to have a strong opinion on it. The missing link for me is exactly how pervasive the non-throwing cocoa completion handlers are. If it turns out that people would have to confront "async(nonthrowing)” in practice (as opposed to being an obscure corner that the compiler implementers have to care about) then it is probably the wrong design.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Naively, to me, the observation that in your introduction you'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></div></div></div></blockquote><div><br class=""></div><div>Agreed.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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></div></div>
</div></blockquote><br class=""></div><div>+1!</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>