> how would you accomplish the following under the current proposal?
We could implement a Future type (as imagined in the async/await proposal),
which would enable something like this:
let futureA = Future { await longCalculationA() }
let futureB = Future { await longCalculationB() }
let futureC = Future { await longCalculationC() }
// Asynchronously waits for a, b, and c to finish before calling
combineCalculations()
let result = await combineCalculations(a: a.get(), b: b.get(), c:
c.get())
If there's no Future type around, it's reasonable to imagine that
DispatchQueue.async would be modified to accept an 'async' closure, so you
could do this:
let group = DispatchGroup()
let queue = DisatchQueue.global()
var a: Any? = nil
var b: Any? = nil
var c: Any? = nil
group.enter()
queue.async {
a = await longCalculationA()
group.leave()
}
group.enter()
queue.async {
b = await longCalculationB()
group.leave()
}
group.enter()
queue.async {
c = await longCalculationC()
group.leave()
}
group.notify {
combineCalculations(a: a, b: b, c: c)
}
A Future type certainly makes this look nicer, though.
-BJ
> On Aug 25, 2017, at 3:49 PM, Jonathan Hull via swift-evolution
> <[email protected]> wrote:
>
> To prove (or potentially disprove) my assertion that this is not just sugar,
> how would you accomplish the following under the current proposal?
>
> let a = async longCalculationA()
> let b = async longCalculationB() //b doesn’t wait for a to complete
> before starting
> let c = async longCalculationC() //c doesn’t wait for a or b
> let result = await combineCalculations(a: a, b: b, c: c) //waits until
> a, b, and c are all available
>
> (Note: this is using my version of async below which doesn’t use futures)
>
> Thanks,
> Jon
>
>
>> On Aug 25, 2017, at 2:13 PM, Jonathan Hull via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I actually really like the idea of using ‘async' to start a computation in a
>> non-blocking way. It is extremely common in real-world code to want to
>> start a few computations/downloads at once in the background and then use
>> the results together...
>>
>> I think full-fledged futures could be a framework thing added on top, but
>> what I would really love to see at the language level is that using ‘async’
>> just allows you to defer calling ‘await’. That is, you could get a value
>> back from something called with async, but you would be forced to await that
>> value before it could be used:
>>
>> var image = async downloadImage() //Image is type UIImage
>> //Do something else here
>> let size = await image.size //The compiler forces me to call await
>> before I can actually use the value
>>
>> This looks somewhat similar to a future, but you can’t interact with it as a
>> separate type of object. The value above is just a UIImage, but with a
>> compiler flag/annotation that forces me to call await on it before it can be
>> accessed/used. The compiler has a lot more freedom to optimize/reorganize
>> things behind the scenes, because it doesn’t necessarily need to make an
>> intermediate object.
>>
>> I don’t think this is just sugar. It adds expressivity and control for a
>> set of very common use-cases which aren’t fully supported by await alone.
>>
>> Thanks,
>> Jon
>>
>>
>>> On Aug 24, 2017, at 4:40 AM, Trevör ANNE DENISE via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hello Swift community,
>>>
>>> I was really interested by the recent Task-based concurrency manifesto and
>>> Concrete proposal for async semantics in Swift.
>>>
>>> Looking at beginAsync() and Futures, I had an idea for a new syntax based
>>> on the `async` keyword, I'd love to hear your feedback about this idea:
>>> https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md
>>>
>>> <https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md>
>>>
>>> Would such a syntax make any sense?
>>>
>>> Thank you ! :)
>>>
>>>
>>> Trevör
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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
