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

[BJ Homer]

Jonathan,

You've mentioned the desire to have 'async' defer calling 'await', but I haven't seen a detailed design yet. For example, is the following code valid?

  let image = async fetchImage()
  let image2 = async fetchImage()
  let deferredThings = [image1, image2]

If so, what is the type of 'deferredThings'? And how does it not count as 'using' the values.

If the above code is not valid, how is this situation better than the suggested use of a Future type to allow concurrent async requests?

  let future1 = Future { await fetchImage() }
  let future2 = Future { await fetchImage() }
  let deferredThings = [future1, future2]

Note that in this example, 'deferredThings' has a concrete type, and we can inspect its values.

You keep bringing up this suggestion, so I must be missing something, but it seems to me that your suggestion is covered by Futures. Why is calling with 'async' better?

-BJ

> On Sep 3, 2017, at 6:01 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution <swift-evolution at swift.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.
> 
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170903/6df09c7d/attachment.html>