<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 28, 2017, at 1:09 PM, Adam Kemp 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; line-break: after-white-space;" class=""><div class="">I decided to split this out to its own thread because it seems orthogonal to other issues being discussed.</div><div class=""><br class=""></div><div class="">When I read this line from the proposal:</div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class="">await decodeImage(dataResource.get(), imageResource.get())</blockquote><div class=""><br class=""></div>It’s not clear to me where the asynchronous call is. There are three function calls on that line. Which ones might actually suspend? You can’t tell by looking at it because there’s only one await keyword (the answer is all 3).</div></div></blockquote><br class=""></div><div>Yes, this is a reasonable concern. We debated it heavily in the Swift 2 timeframe when introducing error handling (as other’s have pointed out, it works the same way).</div><div><br class=""></div><div>This is a tradeoff between the readability benefits of marking non-obvious control flow vs the readability disadvantage of having noise in the code. Requiring marking on every async or throwing call is particularly bad in the case of chaining. Compare:</div><div><br class=""></div><div> let x = try (try (try a.foo()).bar()).baz()</div><div class="">vs:</div> let x = try a.foo().bar().baz()<div class=""><br class=""></div><div class="">In the Swift 2 timeframe, we decided that in many cases, it is mostly obvious what APIs can throw, so one marker is enough. That said, there ARE potentially confusing cases, and some programmers may want to be more explicit about marking. This is why the compiler allows you to explicitly mark subexpressions if you’d like.</div><div class=""><br class=""></div><div class="">I believe that this design has served the community well, and I haven’t heard of serious problems with it. I’m pretty confident that async following the same model will have similar success.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>