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
> <[email protected]> wrote:
>
>
>>> 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]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
