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

[Chris Lattner]

On Sep 3, 2017, at 5:01 PM, Jonathan Hull <jhull at gbis.com> wrote:
>> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Sep 3, 2017, at 4:00 AM, David Hart <david at hartbit.com <mailto: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.
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170904/928f0f78/attachment.html>