On 22 Jul 2015 at 15:16, Michael Caisse wrote:
On 07/22/2015 09:01 AM, Niall Douglas wrote:
Futures gives you the option of monadic programming, and they enforce strict operation ordering very succintly. They are the right choice for file i/o, just as async_result is the right choice for network i/o.
Is there somewhere in the documentation/rational that you explain this (right choice) comparison further?
There once was, but I deleted it as it generated emails to me telling me why I was wrong :) I don't mind restoring such a section now that I have lightweight futures which do I think address most of the problems that the async_result camp have with futures. Do you think I should incorporate this rationale into the design rationale, the tutorial, or the FAQ? After all, the choice of futures is strictly speaking not the controversial choice. They are the STL choice, and if anything it should be controversial to not be choosing the STL choice rather than the other way round. I also feel a bit wary of getting too deeply into futures because I know the monadic programming camp (let's call them the Bartoz camp) aren't going to be happy with my interpretation of "monad". But if you and the community feel I need to justify the choice of futures as the async operation reference mechanism, I can do that. In any case I will need to discuss the reason I deliberately allow implicit type slicing between afio::future<T> and afio::future<void>, I already can see gnashing of teeth is going to happen from that design decision, and that could be part of a wider discussion. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/