Re: [boost] [outcome] To variant, or not to variant?

...

Hmm, maybe you could also implement expected, and that would kinda eliminate the need for a Boost.Outcome?

My original idea was to implement my idea of expected, but I took a detour through never-valueless variant<> first.

Would you be intending to submit your variant2 into Boost, along with an expected implementation sometime soon? You see, from my perspective, getting Outcome into Boost is nothing like as important as getting **any** sort of variant-stored result<T> type thing into Boost. I need one of those into Boost to make getting AFIO v2 into Boost feasible as every single AFIO API returns a result<T>. In other words Peter, if you'd like to do the heavy lifting getting your own Outcome implementation extending Variant2 into Boost instead of me ... I'm all for it. I'll still be implementing my agreed changes to my own Outcome as lots of my code depends on my specific formulation, and I don't want a Boost dependency anyway. But most of the work of getting a Boost library past review is not implementing and testing a high quality implementation, it's all the other stuff like endless documentation and indeed, writing 300+ emails as part of a two week long review. If I could skip all that other stuff because you were taking it on, I'd be **overjoyed**. I could get back to working on AFIO v2 instead, a big gain for me. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/