On Sep 3, 2017, at 5:01 PM, Jonathan Hull <jh...@gbis.com> wrote: >> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On Sep 3, 2017, at 4:00 AM, David Hart <da...@hartbit.com >>> <mailto: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. > > Would it be possible to have the manifesto be a series of proposals then? I > really think it is important for us to look at how all of these things fit > together. I agree that async/await should come first, but looking at how > concrete things like Futures would work may help to inform the design of > async/await. We should do the back-propigation in our design before anything > is locked in…
Sure, that would be great. I don’t have time to write up a futures proposal myself, but I’d be happy to contribute editorial advice to someone (or some group) who wants to do so. > The thing I would most like to see as a quick follow-on to async/await is the > ability to use the ‘async’ keyword to defer ‘await’. This keeps coming up, and is certainly possible (within the scope of the swift grammar) but a decision like this should be driven by a specific cost/benefit tradeoff. That tradeoff decision can only be made when the futures API has a specific proposal that people generally agree to. Because of this, I think that the Futures proposal should be a *library only* proposal on top of the async/await language stuff, and them mention something like “async foo()” as a possible future extension - the subject of its own proposal. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
