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/