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::vector<std::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<std::function<void(const std::future &)>> nonconsuming; std::function<void(std::future)> consuming; void operator()(std::future v) { for(auto &c : nonconsuming) c(v); } consuming(v); }; ... and now do future.then(many_continuations()); I'm simply building that same functionality straight into my future instead of having external code bolt it on.
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/