Quite a bit of feedback from here, from SG14 and from Reddit expressed
disappointment that Outcome doesn't implement the LEWG expected.
basic_monad makes implementing a fully compliant expected just a
few hours of work, so I went ahead and added one today and you can see
its reference docs at
https://ned14.github.io/boost.outcome/group__expected.html. These are
the known deviations from the LEWG proposal:
* P0323R1 doesn't yet specify what will be done if you try accessing an
expected which is valueless due to exception. We throw a
bad_expected_access<void> in this situation as that seemed sensible. If
the LEWG proposal decides on something different, this implementation
will change to track the LEWG proposal.
* unexpected_type<E> is implemented as an expected and it lets
the basic_monad machinery do the implicit conversion to some expected.
* Types T and E cannot be constructible into one another.
* expected defaults E to error_code_extended. If you don't like
this, predefine the BOOST_OUTCOME_EXPECTED_DEFAULT_ERROR_TYPE macro.
* The ordering operators are not implemented due to
https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/
So now you get in Outcome expected; option<T>, result<T> and
outcome<T>. And the Expected implementation ought to be drop in
compatible with any future C++ 20 standard.
How would people prefer the Outcome tutorial to now go? Should it
mention expected at all? Or should it get its own tutorial page
(which will look very similar to the tutorial for result<T>).
Which order should they be in? Is expected easier than outcomes or
the other way round?
Niall
--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
