Re: [boost] Outcome v2

...

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.

I did some benchmarking before making the change to non-variant storage, and found a worst case performance loss of 3-6% depending on compiler. And by worst case, I mean where we do nothing other than return outcomes, and it's 3 CPU cycle hit over ten outcomes returned. I think we'll live. I also did some benchmarking of a std::variant based toy outcome v2 and found compile times to be unacceptably high. The present v2 outcome requires about 4 seconds minimum per compiland, most of which stems from which is unavoidable. std::variant was adding 2 seconds to that, so up to a 50% compile time increase just for naive usage. Just because we don't store strict value-or-error doesn't mean we can't pretend we do in the API. And it eliminates so much special casing for achieving never-empty guarantees etc, it's a lot less work for the compiler and me the developer. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/