Isn’t async / await an evolution over Promises / Tasks / Futures? AFAIK in JS, any function that returns a promise can be ‘await’ upon, and underneath, to be able to await, a function has to return a promise. Marking a function async in JS, tells the consumer that some await are going on inside, and it’s impossible to use await outside of an async marked function. I believe swift is going that direction too. Futures / Promises are the foundation on which async / await can truly express as it formalizes the boxing of the result types. What would be interesting is async being based on a protocol FutureType for example, so you can bring your own library and yet, leverage async / await
On Aug 25, 2017, 20:50 -0400, Jonathan Hull <jh...@gbis.com>, wrote: > > > On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise > > <trevor.anneden...@icloud.com> wrote: > > > > ============================================================= > > > Jonathan Hull jhull at gbis.com > > > 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. > > > > As for the message of Wallacy I'd be interested the pros and cons of hiding > > the implementation details ! :) > > > > > > > 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 > > > > Would this be implemented differently than with Futures? I don't have much > > experience with concurrency, but I don't see how this would be handled > > differently than by using Futures, internally ? (at least for this case) > > > > It looks/behaves very similar to futures, but would potentially be > implemented differently. The main difference is that the resulting type is > actually the desired type (instead of Future<Type>) with a compiler flag > saying that it needs to call await to be used. Behind the scenes, this could > be implemented as some sort of future, but the compiler has a lot more > freedom to rearrange things to be much more efficient because there is no > affordance for the user to introspect or cancel. So for example, it might > actually change: > > let image = async downloadImage() > let size = await image.size > > to: > > let size = await downloadImage().size > > This would depend on the other code around it, but the compiler has much more > freedom to avoid creating intermediate values, or even to create different > types of intermediate values which are more efficient for the situation at > hand. > > Given that as a base, it would be trivial to create a framework offering true > Futures (which allow cancelling, etc…) > > Thanks, > Jon >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
