Boost logo

Boost :

Subject: Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-02 22:37:10

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

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

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?


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at