[swift-evolution] Question about async await

[Nathan Gray]

Based on that thread and others it appears that Chris and Joe are both
alert to the danger that comes with queue-hopping inside a single scope, so
hopefully we won't end up in that world.

On Mon, Sep 25, 2017 at 3:13 PM, Adam Kemp via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Functional Programmer, iOS Developer, Surfs Poorly
http://twitter.com/n8gray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170925/cd797c4d/attachment.html>