[swift-evolution] Question about async await

[Jean-Daniel]

> Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp at apple.com> a écrit :
> 
> 
>> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>> This doesn't have to be the case, actually.  The intrinsics as Chris described them wouldn't be sufficient, but you could require a "current queue" to be provided when kicking off an async function from scratch, as well as any other "async-local" context information you wanted (e.g. QoS and the other things that Dispatch tracks with attributes/flags that are generally supposed to persist across an entire async operation).
>>> 
>> 
>> My response was about the ‘implicitly’ part. I hope we will get a rich API that let us specify return queue, QoS and more, but how do you plan to fulfill the « current queue » requirement implicitly ?
> 
> My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK, there is not DispatchQueue Local Storage yet. Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).

That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.