For boost-dev's information:
https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stability_wg21_paper_will/?ref=share&ref_source=link
--- cut --
I am pleased to announce that Outcome v2, rewritten to fulfil the Boost
peer review feedback from May and only reaching feature completeness
three weeks ago, has been successfully deployed into two complex
libraries which were heavily using Outcome v1. Lots of bug fixes and
maturity has resulted, and if you were holding off on deploying Outcome
into your own code until now, now is the time!
The code itself is now ready for a second Boost peer review, it has all
the same testing that v1 had, and I am highly confident as to its
quality. What solely remains before Outcome v2 can reenter the Boost
peer review queue for a second review is the documentation which remains
parlous (and any help with it is greatly appreciated!), and the
"Boostification" cronjob script as the peer review wants a "pure Boost"
submission. I am also going to have to fix a number of bugs in
Standardese the documentation tool first, it currently segfaults when
fed the Outcome headers :). @foonathan's tool shows lots of promise, it
does far better with C++ 17 than doxygen, just need to shave off some
rough edges in the tool.
What comes before that though is writing a WG21 paper P0762R0
summarising the Boost peer review which led to the stripped down,
barebones v2 `result` design and the rationale for the design
deviations from `expected` as according to the Boost peer review
feedback. If WG21 feel warm feelings about a `std::result` after
reading P0762R0, then I will prepare a formal standardisation proposal
for the Library Evolution Working Group (LEWG) and get the ball rolling
for standardisation by attending meetings from 2018 onwards until it's
through. I'll announce any draft D0762R0 here when it's ready for people
to comment and give feedback on soon.
My thanks to everyone here on Reddit, on boost-dev, on SG14 low latency,
and privately who have helped out with testing, documentation, and so
much more in making this library happen. I know those coming from
Rust-land feel amazement how long it has taken C++ to replicate Rust's
`Result`, but I'm very sure ours is enormously superior to theirs
already simply by doing so much less because it doesn't need to. Taking
time to get design **right** is one of the big things which continues to
separate C++ from the upstart systems programming languages. Long may it
continue!
--- context ---
Outcome provides a C++ 14 STL-quality `result` and an `outcome` implementation of success|failure value transports, and is
expected to pass a second Boost peer review and be submitted for C++
standardisation as the lowest level of an overall framework as proposed by:
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf
C++ Monadic interface
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r2.pdf A
proposal to add a utility class to represent expected object (Revision 4)
The idea is that result/outcome are the extremely lightweight
struct-like success|failure value transports suitable for usage in
public APIs, whereas expected is the much richer variant-like monadic
success|failure value transports, and everything participates together
under P0650R0.
Outcome is a pure header only library with no dependencies. It works
best with C++ 17 and Concepts enabled, but can work with C++ 14 on these
compilers or better:
- clang 4.0 (5.0 required for Windows)
- GCC 7
(VS2017 Update 3 RTM is supposed to work too according to Microsoft, my
thanks to them for swiftly fixing the several ICEs I reported)
Github: https://github.com/ned14/outcome
Docs (highly incomplete): https://ned14.github.io/outcome/
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
