The discussions are interesting, but when they evolve into communal design from a simple review things get ... complicated. Maybe if we kept reviews more focused on thumbs up/down and criticism and support rather than "design" they might be less of a death march and we might encourage more people to participate in reviews.
In this spirit, I have got a question to Niall, or whoever who used the library in their real projects: did the use cases required to change the state of a once constructed `outcome`?
I gave many examples throughout the review of changing the state of existing outcomes. Indeed, almost every AFIO object init function implementation does so, we construct an empty or valued result<T> on the stack and fill it in over time as part of the "two phase construction" used throughout AFIO. Also, in KernelTest, there is some constexpr code which statically constructs a std::array<outcome<T>, N> at compile time exactly matching the number of parameter permutations which will be run. After the test has finished, empty outcome<T> means test was skipped or death test failed, valued means test passed, errored means test errored, excepted means test threw an exception. So assignment of Outcomes, well I use it frequently. I've also passed in outcomes by lvalue ref to a set of filtering callbacks, and each callback may or may not change their state as part of their execution. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/