Re: [boost] [next gen future-promise] What to call the monadicreturn type?

Subject: Re: [boost] [next gen future-promise] What to call the monadicreturn type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-28 10:19:13

On 28 May 2015 at 16:25, Peter Dimov wrote:

> > I also want a big semantic change that error returns are not exceptional. 
> > We hugely underuse std::error_code in STL C++ unfortunately. I am not one 
> > of those people who believes exceptions are evil, and ban them in the 
> > language as all the new system languages seem to. I also have no love for 
> > forcing everything through the return code as with C and Rust, but I do 
> > think there is a middle ground between good outcomes, bad outcomes, and 
> > exceptional outcomes which is easy to program, easy to conceptualise, and 
> > easy on the compiler.
> 
> There could be a misunderstanding. When I say that your type is 
> future<expected<T, error_code>>, I don't mean any specific future or 
> expected implementations such as std::future or boost::expected. What I mean 
> is a future-like type, having the interface of std/boost::future, and an 
> expected-like type, having (a subset of) the interface of 
> std/boost::expected.

For reference, I originally began all of this nine months ago with a 
future<expected<shared_ptr<async_io_handle>, error_code>>. I found it 
obtusive and irritating to work with because of the nested layers of 
API e.g. if(f.has_value()) f.get().value_or(...) etc. I found myself 
wanting to wrap future<expected<shared_ptr<async_io_handle>, 
error_code>> into a class which implements a flat convenience API.

> You could still implement your own future<> and expected<> if the existing 
> ones are unfit. My point is purely that these are independent concepts and 
> there is no real need to couple them into one type, with a hardcoded 
> error_code to boot.

error_code is pretty great in fact. I've tried to come up with an 
error transmitting type which is better for the same light weight 
spec, and I failed after several months of effort.

I actually now believe error_code has an optimal design which cannot 
be improved upon without losing that its storage is just an int and a 
pointer and is therefore a completely trivial type. That is a very 
rare opinion for me to hold on any part of the STL, but I became 
quite impressed with the design once I failed to improve on it.

My sole thing I would change if I could is that I really wish it 
stored a ssize_t not an int. An additional void * in its storage 
could also be useful.

> So far, you've stated that you like that your type is constructible from T, 
> error_code or exception_ptr. I suppose a future<expected<T, error_code>> may 
> not be as convenient.  

It wasn't fun and convenient to use when I started out down this 
path. I also didn't like how many opcodes were generated by the 
compiler for very simple operations, especially on MSVC.

> Are there other ways in which the interface of future<expected<T,
> error_code>> is deficient? 

I very much like the expected API and design. Why I choose not to use 
it comes down to the lack of a flat API as mentioned above, and 
compile times.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/