Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-05-26 05:07:05
On May 25, 2015 7:09:57 PM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
> On 25 May 2015 at 23:35, Vicente J. Botet Escriba wrote:
> Names suggested so far are maybe, result, holder, value.
I'm still trying to understand use cases to help guide naming. However, among those choices, "result" seems best. That said, one often refers to the result of a function, so discussing a function that returns a "result" would get awkward. Perhaps "retval" would convey the idea well enough and be less awkward?
> I am simply proposing subclassing monad<T, consuming> with a thread
> unsafe subclass called <insert name here>. It has almost the same API
> as future as it shares a common code implementation.
> > > Options are:
> > >
> > > * result<T>
> > sync or async result?
> A result<T> has most of the future<T> API with the set APIs from
> promise<T>. So you might do:
> result<int> v(5);
> v.get(); // throws foo
> v.get(); // throws system_error(error_code)
Can one ask whether it contains an exception or an error_code? Can one retrieve the exception or error_code without calling get() with, say, get_exception() and get_error_code()?
> > > * maybe<T>
> > we have already optional, isn't it?
> True. But I think a monadic transport supersets optional as it can
> have no value. So:
> result<int> v;
> v.get(); // throws no_state.
Here you show has_value(). Are there has_exception() and has_error_code()?
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk