Dear Boost, I've been hard at work refactoring Outcome to match the peer review a few weeks ago. Much comment at the time mentioned the poor experience of the reference API docs, so can I get a community check of this: https://dedi4.nedprod.com/static/result-v2/doc_result.html This was generated by the new C++ reference docs generator https://github.com/foonathan/standardese. You'll no doubt spot quite a few formatting bugs, Jonathan says he's onto them. But the usage of libclang rather than doxygen's broken C++ parser clearly shows a lot of benefit, it's just standardese still remains quite a lot short in terms of necessary features to make output fully correct. I won't give the changelog for Outcome v2 result<T> over Outcome v1 yet. Let's see how you fare with the above reference API docs first. But as you'll note, there is considerable change over before as we now slot into a niche not occupied by Expected nor EitherMonad, indeed this now looks much more like Robert's or Lawrence Crowl's slimmed down object. This result<T> is approx 0.6 CPU cycles per stack frame unwound slower which I feel is acceptable in exchange for no more variant storage, which in turn released lots of SFINAE budget for me. (FYI v2 outcome<T> isn't done yet, but it will extend v2 result<T>) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/