On 11/07/2017 12:53, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Indeed, outcome<> actually reuses 90% of result<>'s implementation by supplying an outcome-ish no-value policy, so it saves me a ton of maintenance and copy and paste as well.
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. However it could be that dropping outcome and having result gain the ability to transform unrelated error types via some free function mechanism would be better. Indeed Andrzej asked for that exact same thing, I gave him one half of a solution.
I would also use union { T t; E e; } in result instead of a struct. :-)
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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/