[swift-evolution] [Concurrency] async/await + actors

[Chris Lattner]

On Aug 18, 2017, at 12:34 PM, Adam Kemp <adam.kemp at apple.com> wrote:
> 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:
> 
> private async void HandleButtonClick(object sender, EventArgs e) {
>     var results = await GetStuffFromNetwork();
>     UpdateUI(results);
> }
> 
> 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.

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:
https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#fix-queue-hopping-objective-c-completion-handlers

> 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:
...
> 
> 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.

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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/b44dc091/attachment.html>