<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for the quick response!<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2017, at 1:15 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="">On Aug 18, 2017, at 12:34 PM, Adam Kemp <<a href="mailto:adam.kemp@apple.com" class="">adam.kemp@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class="">For instance, say you’re handling a button click, and you need to do a network request and then update the UI. In C# (using Xamarin.iOS as an example) you might write some code like this:<br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">private async void HandleButtonClick(object sender, EventArgs e) {</div><div class=""> var results = await GetStuffFromNetwork();</div><div class=""> UpdateUI(results);</div><div class="">}</div></blockquote><div class=""><br class=""></div>This event handler is called on the UI thread, and the UpdateUI call must be done on the UI thread. The way async/await works in C# (by default) is that when your continuation is called it will be on the same synchronization context you started with. That means if you started on the UI thread you will resume on the UI thread. If you started on some thread pool then you will resume on that same thread pool.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I completely agree, I would love to see this because it is the most easy to reason about, and is implied by the syntax. I consider this to be a follow-on to the basic async/await proposal - part of the Objective-C importer work, as described here:</div><div class=""><a href="https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#fix-queue-hopping-objective-c-completion-handlers" class="">https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#fix-queue-hopping-objective-c-completion-handlers</a></div></div></div></div></blockquote><div><br class=""></div><div>Maybe I’m still missing something, but how does this help when you are interacting only with Swift code? If I were to write an asynchronous method in Swift then how could I do the same thing that you propose that the Objective-C importer do? That is, how do I write my function such that it calls back on the same queue?</div><div><br class=""></div><div>In my mind, if that requires any extra effort then it is already more error prone than what C# does.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Another difference between the C# implementation and this proposal is the lack of futures. While I think it’s fair to be cautious about tying this proposal to any specific futures implementation or design, I feel like the value of tying it to some concept of futures was somewhat overlooked. For instance, in C# you could write a method with this signature:</div></div></div></blockquote>...<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">The benefit of connecting the async/await feature to the concept of futures is that you can mix and match this code freely. The current proposal doesn’t seem to allow this. </div></div></div></blockquote><div class=""><br class=""></div><div class="">The current proposal provides an underlying mechanism that you can build futures on, and gives an example. As shown, the experience using that futures API would work quite naturally and fit into Swift IMO.</div></div></div></blockquote><br class=""></div><div>I feel like this is trading conceptual complexity in order to gain compiler simplicity. What I mean by that is that the feature feels harder to understand, and the benefit seems to be that this feature can be used more generally for other things. I’m not sure that’s a good tradeoff.</div><div><br class=""></div><div>The other approach, which is to build a specific async/await feature using compiler transformations, may be less generic (yield return would have to work differently), but it seems (to me) easier to understand how to use.</div><div><br class=""></div><div>For instance, this code (modified from the proposal):</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>@IBAction func buttonDidClick(sender:AnyObject) { </div><div> doSomethingOnMainThread();</div><div><div class=""> beginAsync {</div></div><div> let image = await processImage()</div><div><div class=""> imageView.image = image</div></div><div><div class=""> }</div></div><div> doSomethingElseOnMainThread();</div><div>}</div></blockquote><br class=""><div class="">Is less straightforward than this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">@IBAction async func buttonDidClick(sender:AnyObject) {</div><div class=""> doSomethingOnMainThread();</div><div class=""> let imageTask = processImage()</div><div class=""> doSomethingElseOnMainThread();</div><div class=""> imageView.image = await imageTask</div><div class="">}</div></blockquote><br class=""><div class="">It’s clearer from reading of the second function what order things will run in. The code from the proposal has a block of code (the callback from beginAsync) that will run in part before the code that follows, but some of it will run after buttonDidClick returns. That’s confusing in the same way that callbacks in general are confusing. The way that async/await makes code clearer is by making it more WYSIWYG: the order you see the code written in is the order in which that code is run. The awaits just mark breaks.</div></body></html>