Re: [boost] Outcome v2

On 12/07/2017 02:18, Niall Douglas wrote:

On 11/07/2017 12:53, Peter Dimov wrote:

...

I would make outcome<> reuse 100% of result<>'s implementation, by stealing another page from your playbook:

class extended_error_code { std::error_code e_; std::exception_ptr x_; };

template<class T> using outcome = result;

That may well happen yet. What held me back was that the universality of EC = error_code is very important in order to use TRY effectively. That's what led to the split design you see today, so you're basically exchanging some purity in the design for ease of programming. TRY is such a boon for not typing boilerplate.

Perhaps: struct extended_error_code : public std::error_code { std::exception_ptr ex; }; template<class T> using outcome = result; This allows generic code to treat EC exactly as a std::error_code (both for method calls and to slice off the exception if they wish). Having said that, this would basically render it impossible to have value + exception *without* an error_code. You could mitigate that by defining a default "there is an exception" error_code (which you might be doing anyway), though it feels a little weird. (Then again, it's probably worse to leave the std::error_code default-constructed.)

A majority of peer review feedback didn't see the need for variant storage. Eliminating it very significantly reduces the complexity of the implementation, it's a big gain. I was able to SFINAE all the constructors because of the compile time budget released by eliminating the variant storage.

If you're going to maintain strict no-value-plus-error semantics then union/variant storage makes sense, as otherwise you're wasting memory. I'm not sure why this would increase complexity.