[boost] [outcome v2] Please comment on new result<T, EC> reference API docs

Subject: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-21 17:41:34

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/