<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 7:17 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.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=""><br class=""><div class=""><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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">I’d be curious to see numbers on the prevalence of try?/! across various kinds of codebases (i.e.: library code, app code, CLI utils, etc). I don’t use try? all that much, but I have used it. I also have found (IMHO) legitimate uses for try! in my unit tests where I want the test logic to be brittle with respect to expected conditions surrounding the test—to fail immediately if those conditions are not as I intend them to be.</div><div class=""><br class=""></div><div class="">If we can write "try? await foo()” (which I think is the right way to position this), will we be able to also write "try await foo()” ? I’d hope that the latter wouldn’t be prohibited… as I think it would just make the former less discoverable. If I’m learning Swift and I see “try? await” on one line, and nearby just “await” it’s easier to assume that the first can produce an error and the second can’t, no?</div><div class=""><br class=""></div><div class="">If I’m honest, I *think* I’d rather we'd always have to be explicit about both try and await… yes it’s more to type, but it’s also a lot clearer about what exactly is happening. And if I always use "do try catch” together it forms a consistent pattern that’s easier to read and easier to learn. If sometimes it’s “do try catch” and sometimes "do await catch” and sometimes just “await" it seems to me we’ve lost some clarity and it’s harder for me to compose my understanding of the rules.</div><div class=""><br class=""></div><div class="">On the other hand, I can’t say I’ve given this a lot of deep thought either :)</div><div class=""><br class=""></div><div class="">—Karim</div><div class=""><br class=""></div></body></html>