<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=""><div>This looks fantastic. Can’t wait (heh) for async/await to land, and the Actors pattern looks really compelling.</div><div><br class=""></div><div>One thought that occurred to me reading through the section of the "async/await" proposal on whether async implies throws:</div><div><br class=""></div><div>If ‘async' implies ‘throws' and therefore ‘await' implies ‘try’, if we want to suppress the catch block with ?/!, does that mean we do it on the ‘await’ ? </div><div><br class=""></div><div><font face="Menlo" class="">guard let foo = await? getAFoo() else { … }</font></div><div><br class=""></div><div>This looks a little odd to me, not not extremely clear as to what is happening. Under what conditions will we get a nil instead of a Foo? Maybe it’s just me or that the syntax is new and I’ll get used to it.</div><div><br class=""></div><div>But it gets even more complicated if we have:</div><div><br class=""></div><div><font face="Menlo" class="">func getAFoo() async -> Foo {</font></div><div><font face="Menlo" class=""> …</font></div><div><font face="Menlo" class="">}</font></div><div><font face="Menlo" class=""><br class=""></font></div><div><font face="Menlo" class="">func getABar() async(nonthrowing) -> Bar {</font></div><div><font face="Menlo" class=""> …</font></div><div><font face="Menlo" class="">}</font></div><div><br class=""></div><div>Now, we have an odd situation where the ‘await’ keyword may sometimes accept ?/! but in other cases may not (or it has no meaning):</div><div><br class=""></div><div><div><font face="Menlo" class="">guard </font></div><div><font face="Menlo" class=""> let foo = await? getAFoo(),</font></div><div><font face="Menlo" class=""> let bar = await? getABar() // Is this an error?? If not, what does it mean?</font></div><div><font face="Menlo" class=""> else { … }</font></div><div></div><div></div><div class=""><font face="Menlo" class=""><br class=""></font></div></div><div><br class=""></div><div>Since this edge of throws/try wasn’t explicitly covered in the write-up (or did I miss it?), was wondering about your thoughts.</div><div><br class=""></div><div>—Karim</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Date: Thu, 17 Aug 2017 15:24:14 -0700<br class="">From: Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>><br class="">To: swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">Subject: [swift-evolution] [Concurrency] async/await + actors<br class=""><br 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=""><br class="">-Chris<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class=""><br class=""></div></body></html>