> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>> On Sep 3, 2017, at 4:00 AM, David Hart <[email protected]
>> <mailto:[email protected]>> 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...
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 feels very natural,
is highly optimizable by the compiler, and it allows for a lot of very common
use-cases which are not covered well by pure async/await. I think it would
have a large impact on the eventual design/implementation of futures (and at
least some impact on the design of async/await).
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
