On 2 Jul 2015 at 15:36, Vinícius dos Santos Oliveira wrote:
Let's look like there is not any support for async code at all. You always know whether it's T or error_code/exception. There was a mention to "impurism" in the thread earlier, but I got lost.
If it's "pure" and "sync-only", then you know false will map to error. The behaviour shouldn't change when you add code to also support async code.
Somewhere in the thread, there were mentions to "this is not async, future is the one that will be async". But I got lost on this one too. Too much motivation spread around.
The inheritance diagram is very easy: future<T> => monad<T> future_result<T> => result<T> future_option<T> => option<T> It's protected inheritance, so only some not all APIs from the base classes on the right hand side are made available in the child class on the left hand side. For example, you can't do future<T>.set_value(). You can however construct a future directly with a value/error/exception to make an already ready future. This is an alternative to make_ready_future() etc. and in fact make_ready_future() simply calls the future constructor with the value. Each of the future types has a corresponding promise type, so: future<T> <=> promise<T> future_result<T> <=> promise_result<T> future_option<T> <=> promise_option<T> Does this make sense? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/