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

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>, 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, 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, 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> 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> 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/