On 26 May 2015 at 19:56, Vicente J. Botet Escriba wrote:
Names suggested so far are maybe, result, holder, value.
Neither result, holder nor value conveys the fact that the value can not be there. maybe<T> has already the connotation T or nothing as optional. There is no place for error_code and exception_ptr. If the type is not related to thread synchronization, here they are some alternative names: probably_value<T>, probable<T>?
probable<T> vs result<T> vs maybe<T>. Hmm, I'll have to think about it.
result<int> v(5); assert(v.get()==5); v.set_value(6); assert(v.get()==6); v.set_exception(foo()); v.get(); // throws foo v.set_error(error_code); v.get(); // throws system_error(error_code) This is quite close to expected, isn't it?
I lean on expected's design yes. I like the expected design. No point inventing a new API after all, we know yours works.
The compiler treats a default initialised monad identically to a void return i.e. zero overhead. Ah, then the to be named type has the additional ready state. This is closer to a valid future with the addition of the promise (setting) interface.
Exactly right. No surprises.
I have no problem. There are not proper and dirty monads. Purist will give you the good name. I see several nested monads. IIUC, the type doesn't has the invalid state, isn't it?
It has valid() on the future<T>. But not on the monad. So I suppose not.
expected integration is very far away for me. I'm even a fair distance from continuations, because getting a std::vector to constexpr collapse is tricky, and you need a std::vectorstd::function to hold the continuations. Why do you need to store store a vector of continuations. You have just one. What am I missing?
It makes my implementation a lot easier if I can add an unknown
number of continuations (non-consuming, therefore they are really C
type callbacks) to some future. Remember I am optionally supporting
Boost.Fiber later on, and I need an extensible and generic way of
firing off coroutines on future signal with minimal #ifdef code
branches all over the place.
Under the Concurrency TS you'd implement this by creating a callable
struct which contains the vector of more continuations, so as an
example:
struct many_continuations
{
std::vector
My main goal is getting AFIO past peer review for now.
As others I'm waiting for a written proposal. But I think this is not on your plans.
Nope. My priority is AFIO. I have about two months to deliver it. We'll go from there after. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/