Does that make more sense?
Let's see. So now, I my understanding is the following. If a programmer decides that certain section of the program (the see of noexcept) requires explicit control flow when it comes to handling "disappointments", Boost.Outcome is just the tool he needs because it offers a set of convenient types, tailored for optimum performance + convinience operators + a dedicated control flow statement hidden under macro BOOST_OUTCOME_TRY.
did I get it right?
Basically yes. If a programmer is feeling that they want to use something like expected<T, E> to return values from functions, they may wish to consider using Outcome instead as I think it'll be more pleasant for them, generate tighter code and help enforce best practice in writing low latency code (i.e. don't let your programmers customise the E in expected<T, E>). As Outcome now also provides a compliant expected<T, E> implementation, users can choose whichever suits them best. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/