[swift-evolution] [Concurrency] Fixing race conditions in async/await example

[Jean-Daniel]

> Le 26 août 2017 à 07:27, Howard Lovatt via swift-evolution <swift-evolution at swift.org> 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.