Howard, with async / await, the code is flat and you don’t have to unowned/weak self to prevent hideous cycles in the callbacks. Futures can’t do that
On Aug 26, 2017, 04:37 -0400, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org>, wrote: > With both he now built in promises in Node8 as well as libraries like > Bluebird there was ample time to evaluate them and convert/auto convert at > times libraries that loved callback pyramids of doom when the flow grows > complex into promise based chains. Converting to Promises seems magical for > the simple case, but can quickly descend in hard to follow flows and hard to > debug errors when you move to non trivial multi path scenarios. JS is now > solving it with their implementation of async/await, but the point is that > without the full picture any single solution would break horribly in real > life scenarios. > > Sent from my iPhone > > On 26 Aug 2017, at 06:27, Howard Lovatt via swift-evolution > <swift-evolution@swift.org> wrote: > > > My argument goes like this: > > > > 1. You don't need async/await to write a powerful future type; you can > > use the underlying threads just as well, i.e. future with async/await is no > > better than future without. > > > > 2. Since future is more powerful, thread control, cancel, and timeout, > > people should be encouraged to use this; instead because async/await are > > language features they will be presumed, incorrectly, to be the best way, > > consequently people will get into trouble with deadlocks because they don't > > have control. > > > > 3. async/await will require some engineering work and will at best make a > > mild syntax improvement and at worst lead to deadlocks, therefore they just > > don't carry their weight in terms of useful additions to Swift. > > > > Therefore, save some engineering effort and just provide a future library. > > > > To turn the question round another way, in two forms: > > > > 1. What can async/wait do that a future can't? > > > > 2. How will future be improved if async/await is added? > > > > > > -- Howard. > > > > > On 26 August 2017 at 02:23, Joe Groff <jgr...@apple.com> wrote: > > > > > > > > > On Aug 25, 2017, at 12:34 AM, Howard Lovatt <howard.lov...@gmail.com> > > > > > wrote: > > > > > > > > > > In particular a future that is cancellable is more powerful that the > > > > > proposed async/await. > > > > > > > > It's not more powerful; the features are to some degree disjoint. You > > > > can build a Future abstraction and then use async/await to sugar code > > > > that threads computation through futures. Getting back to Jakob's > > > > example, someone (maybe the Clang importer, maybe Apple's framework > > > > developers in an overlay) will still need to build infrastructure on > > > > top of IBActions and other currently ad-hoc signalling mechanisms to > > > > integrate them into a more expressive coordination framework. > > > > > > > > -Joe > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
