Sent from my iPhone
> On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution > <[email protected]> wrote: > > C# had futures (in the form of the Task Parallel Library) before it had > async/await. If you could see how much async/await has revolutionized C# > programming you would not be making this argument. It is night and day. > Asynchronous code is so much clearer with this feature than without. You can > write code the is simpler and safer at the same time. > > This isn’t an either/or proposition. We should have both, and they should > work together. > +1 > -- > Adam Kemp > >> On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution >> <[email protected]> wrote: >> >> 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 > _______________________________________________ > 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
