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/