Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 19:36:26
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
> > 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)
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
> > 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
std::vector<std::function<void(const std::future &)>> nonconsuming;
void operator()(std::future v)
for(auto &c : nonconsuming)
... 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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk