[swift-evolution] [Concurrency] A slightly different perspective

[David Hart]

> On 3 Sep 2017, at 18:03, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>>> On Sep 3, 2017, at 4:00 AM, David Hart <david at 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170904/d2afbcc1/attachment.html>