<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">First of all, thank you to everyone for reacting ! :)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Taking the messages in chronological order :</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Wallacy <<a href="mailto:wallacyf@gmail.com" class="">wallacyf@gmail.com</a>> </blockquote></div><blockquote type="cite" class="">Interesting, its syntax seems to improve the "fire and forget" issue.<div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.6px; margin-top: 0px; margin-bottom: 0px; font-stretch: normal; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""><span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">@IBAction</span> <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">func</span> <span class="inbox-inbox-pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">buttonClicked</span>() {
async <span class="inbox-inbox-pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">downloadAndUpdateImageView</span>()
}</pre></div></blockquote><div class=""><br class=""></div><div class="">While this could be nice it would indeed not be needed in this case @IBAction methods were async as Chris Lattner says.</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.6px; margin-top: 0px; margin-bottom: 0px; font-stretch: normal; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""></pre><blockquote type="cite" class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.6px; margin-top: 0px; margin-bottom: 0px; font-stretch: normal; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""><span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">func</span> <span class="inbox-inbox-pl-en" style="box-sizing: border-box; color: rgb(111, 66, 193);">SomethingUsingUser</span>() <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">-></span> <span class="inbox-inbox-pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">Void</span> {
<span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">var</span> user <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">=</span> await <span class="inbox-inbox-pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">getUser</span>() <span class="inbox-inbox-pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"><span class="inbox-inbox-pl-c" style="box-sizing: border-box;">//</span>Only here</span>
<span class="inbox-inbox-pl-c" style="box-sizing: border-box; color: rgb(106, 115, 125);"></span> <span class="inbox-inbox-pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">printf</span>(user.<span class="inbox-inbox-pl-smi" style="box-sizing: border-box;">age</span> <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">></span> <span class="inbox-inbox-pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">21</span> <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">?</span> <span class="inbox-inbox-pl-s" style="box-sizing: border-box; color: rgb(3, 47, 98);"><span class="inbox-inbox-pl-pds" style="box-sizing: border-box;">"</span>Let's Drink<span class="inbox-inbox-pl-pds" style="box-sizing: border-box;">"</span></span> <span class="inbox-inbox-pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">:</span> <span class="inbox-inbox-pl-s" style="box-sizing: border-box; color: rgb(3, 47, 98);"><span class="inbox-inbox-pl-pds" style="box-sizing: border-box;">"</span>See you later!<span class="inbox-inbox-pl-pds" style="box-sizing: border-box;">"</span></span>)</pre></blockquote><div class=""><br class=""></div></div><div class=""><div class=""><br class=""></div><div class="">I don't have a lot of experience with async await syntaxes, but if I understand correctly the proposal and the way async/await works, doing that inside of a non-async function would be problematic as this would block the thread and wouldn't clearly show that calling your function would be blocking (being forced to marked a function as async and the imposed language syntax at call site fixes this issue).</div></div><div class="">That's why I only proposed "<i class="">async outside of await" </i>and not "<i class="">await outside of async"</i>, because async outside of await would still enable the compiler to prevent issues like the aforementioned one thanks to a <i class="">Future like </i>behaviour.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">=============================================================</div><div class=""><br class=""></div><div class=""></div><br class=""><blockquote type="cite" class="">Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> </blockquote><blockquote type="cite" class=""><div class=""><br class=""></div><div class=""><div class="">Yes, it is entirely possible that we will want to provide more syntactic sugar than the proposal suggests: the proposal is intentionally designed to be minimal, so we can get it in place, get experience using it, then decide whether any specific syntactic pain point is significant enough to be worth adding additional sugar/complexity.</div><div class=""><br class=""></div><div class="">As has been mentioned in other threads, the hope is that “beginAsync” is actually extremely rare in practice. If that is the case, there is little point to sugaring it.</div><div class=""><br class=""></div><div class="">-Chris</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The second part of my proposition is indeed more syntactic sugar if beginAsync ends up being rarely used in practice, but<b class=""> about the first part of my explanation (using async inside of async functions to provide a <i class="">future like </i>syntax), would it enable to both to drastically reduce the syntactic complexity of async/await and to hide away implementation giving more freedom for future Swift releases as Wallacy and Jonathan Hull suggested?</b></div><div class=""><br class=""></div><div class="">Thank you ! :)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">=============================================================</div><div class=""></div><blockquote type="cite" class=""><div class="">Wallacy <<a href="mailto:wallacyf@gmail.com" class="">wallacyf@gmail.com</a>> </div><div class=""></div></blockquote><div class=""><blockquote type="cite" class="">Using only async/await is pretty easy to learn and teach.</blockquote></div><blockquote type="cite" class=""><div class=""><div class="">And after that, "Future" can be implement in any way because will not be a</div><div class="">public API anymore (I do not know, but there may also be some opportunities</div><div class="">for optimization as well), and we only need to care about when we need to</div><div class="">"keep the reference" from some async call.</div><div class=""><br class=""></div><div class="">And possibly, they will not need to create any Future type! The variable</div><div class="">type will be "async User" as long as it is not "unwrapped". (</div><div class="">suspend/defer/abandon still possible)</div></div></blockquote><div class=""><br class=""></div>Using async at call site would indeed (in my opinion) make async/await easier to learn (especially given the parallel with optional unwrapping and similarities with other behaviours of Swift, including possible async vars of Actors maybe?).<div class=""><br class=""></div><div class=""><b class="">I'd be interested to know what would be the ramifications of promoting async at type level as you propose, what would be the pros and cons of such an approach ? I'd be interested to get other opinions about it ! :)</b></div><div class=""><br class=""></div><div class="">In my first idea async at call site would be synthesising a Future<T> just as T? synthesises Optional<T>, but I'd be interested to know too if hiding implementation details would have any advantages for the future of Swift ? Making things more flexible maybe?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">=============================================================</div><div class=""><blockquote type="cite" class="">Jonathan Hull jhull at <a href="http://gbis.com" class="">gbis.com</a> </blockquote></div><div class=""><blockquote type="cite" class="">This looks somewhat similar to a future, but you can’t interact with it as a separate type of object. The value above is just a UIImage, but with a compiler flag/annotation that forces me to call await on it before it can be accessed/used. The compiler has a lot more freedom to optimize/reorganize things behind the scenes, because it doesn’t necessarily need to make an intermediate object.</blockquote></div><div class=""><div class=""></div><div class=""><br class=""></div></div><div class="">As for the message of Wallacy I'd be interested the pros and cons of hiding the implementation details ! :)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class="">To prove (or potentially disprove) my assertion that this is not just sugar, how would you accomplish the following under the current proposal?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let a = async longCalculationA()</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let b = async longCalculationB() //b doesn’t wait for a to complete before starting</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let c = async longCalculationC() //c doesn’t wait for a or b</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let result = await combineCalculations(a: a, b: b, c: c) //waits until a, b, and c are all available</div></blockquote></div><div class=""><br class=""></div><div class="">Would this be implemented differently than with Futures? I don't have much experience with concurrency, but I don't see how this would be handled differently than by using Futures, internally ? (at least for this case)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">=============================================================</div><div class=""><blockquote type="cite" class="">Florent Vilmart florent at <a href="http://flovilmart.com" class="">flovilmart.com</a> </blockquote></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class="">Probably with:</div><div class=""><br class=""></div><div class="">let a = longCalculationA()</div><div class="">let b = longCalculationB() //b doesn’t wait for a to complete before starting</div><div class="">let c = longCalculationC() //c doesn’t wait for a or b</div><div class="">let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits until a, b, and c are all available</div></blockquote><br class=""></div><div class="">This isn't possible with the proposed async/await syntax, is it ? </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Thank you everyone !! :)</b></div></body></html>