Re: [boost] Ternary logic programming (was: Re: [variant] Maintainer)

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 
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/