I just don't see that async/await adds enough to warrant a language change. You can write Future on top of GCD and a future type can do more, like having a cancel, having a timeout, and giving control over what thread is used.
-- Howard. On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution < [email protected]> wrote: > 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 <[email protected]>, wrote: > > > On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
