<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 19, 2017, at 8:14 AM, Karim Nassar 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=""><div class="">This looks fantastic. Can’t wait (heh) for async/await to land, and the Actors pattern looks really compelling.</div><div class=""><br class=""></div><div class="">One thought that occurred to me reading through the section of the "async/await" proposal on whether async implies throws:</div><div class=""><br class=""></div><div class="">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></div></blockquote><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=""><br class=""></div><div class=""><font face="Menlo" class="">guard let foo = await? getAFoo() else { … }</font></div></div></div></blockquote><div><br class=""></div><div>Interesting question, I’d lean towards “no, we don’t want await? and await!”. My sense is that the try? and try! forms are only occasionally used, and await? implies heavily that the optional behavior has something to do with the async, not with the try. I think it would be ok to have to write “try? await foo()” in the case that you’d want the thrown error to turn into an optional. That would be nice and explicit.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div></div></body></html>