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. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
