> On 2 Sep 2017, at 20:24, Chris Lattner via swift-evolution > <[email protected]> wrote: > > On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution > <[email protected]> wrote: >> I've been following the conversations around Chris Lattner's intriguing >> async/await proposal and would like to offer my own take. I feel that the >> proposal as written is almost perfect. My suggestions for improving it are >> not highly original -- I think they have all come up already -- but I'd like >> to present them from my own perspective. >> >> 1. Fixing "queue confusion" *must* be part of this proposal. The key bit of >> "magic" offered by async/await over continuation passing is that you're >> working in a single scope. A single scope should execute on a single queue >> unless the programmer explicitly requests otherwise. Queue hopping is a >> surprising problem in a single scope, and one that there's currently no >> adequate solution for. > > As mentioned downthread, the “contextualizing” thread is one way to address > this. > >> 2. The proposal should include some basic coordination mechanism. The >> argument against returning a Future every time `await` is called is >> convincing, so my suggestion is to do it from `beginAsync`. The Future >> returned should only be specified by protocol. The protocol can start with >> minimal features -- perhaps just cancellation and progress. There should be >> a way for programmers to specify their own, more featureful, types. (The >> proposal mentions the idea of returning a Bool, which is perhaps the >> least-featureful Future type imaginable. :-) > > Please don’t read too much into the beginAsync API. It is merely a strawman, > and intended to be a low-level API that higher level abstractions (like a > decent futures API) can be built on top of. I think it is important to have > some sort of primitive low-level API that is independent of higher level > abstractions like Futures. > > This is all a way of saying “yes, having something like you propose makes > sense” but that it should be part of the Futures API, which is outside the > scope of the async/await proposal.
But it would be nice for all high-level APIs that conform to a Awaitable protocol to be used with await without having to reach for a get property or something similar everytime. > -Chris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
