> On 3 Sep 2017, at 18:03, Chris Lattner <clatt...@nondot.org> wrote: > > >>> On Sep 3, 2017, at 4:00 AM, David Hart <da...@hartbit.com> wrote: >>> >>> 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. > > The futures API that is outlined in the proposal is just an example, it isn’t > a concrete pitch for a specific API. There are a bunch of improvements that > can (and should) be made to it, it is just that a futures API should be the > subject of a follow-on proposal to the basic async/await mechanics.
Of course, but perhaps an Awaitable protocol could be part of the proposal, no? In that case, even this proposal does end up being accepted and implemented for Swift 5, but a Promise proposal does not, a protocol would be available for third party futures and promises to blend well with await. > -Chris > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
