[boost] [outcome] Added LEWG expected<T, E> implementation, what about the tutorial?

Subject: [boost] [outcome] Added LEWG expected<T, E> implementation, what about the tutorial?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-17 12:32:04

Quite a bit of feedback from here, from SG14 and from Reddit expressed
disappointment that Outcome doesn't implement the LEWG expected<T, E>.
basic_monad makes implementing a fully compliant expected<T, E> 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<void, E> and it lets
the basic_monad machinery do the implicit conversion to some expected<T, E>.

* Types T and E cannot be constructible into one another.

* expected<T, E> 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<T, E>; 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<T, E> 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<T, E> easier than outcomes or
the other way round?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/