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 < [email protected]> wrote: > > 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]> 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 > > -- Functional Programmer, iOS Developer, Surfs Poorly http://twitter.com/n8gray
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
