> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution
> <[email protected]> wrote:
>
>> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
