[swift-evolution] New async keyword usage

[BJ Homer]

> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20170825/aeef6860/attachment.html>