> Le 26 août 2017 à 07:27, Howard Lovatt via swift-evolution > <[email protected]> a écrit : > > 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?
Everything that is described in the proposal, like avoiding the pyramid of doom, simplify error handling of asynchronous calls, and so avoid many bug and bad coding practices. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
