2015-07-22 9:27 GMT+08:00 Niall Douglas
Quite a few people have disliked (a) the choice of future continuations over ASIO's async_result pattern and (b) the batch API. Those two observations have come up repeatedly - Bjorn and Robert on this list have both publicly found issue there, and neither was alone in their opinion.
I'm not dropping futures in favour of async_result - I don't think that helps ease of use because in file i/o you really do want strong i/o ordering, and you usually don't care about ordering much for network i/o. Forthcoming C++ 1z coroutines are also futures based, and that decision is not going to be reversed now. Futures are our future as it were.
async_result is more flexible and it allows the use of future, e.g. `s.async_xxx(..., asio::use_future)`, and you can customize your afio::use_future to use your lightweight futures. What's your real concern of async_result? The verbosity of specifying afio::use_future? Since you mentioned C++ 1z coroutines, the asio way actually allows zero-overhead adaption without using a future, e.g. see: https://github.com/jamboree/act Is any performance reason in preferring strict future API to the callback style?