Just to clarify your question. Outcome v2 will provide a number of ways for the user to customize the interface: different templates, hooks, ability to derive from base templates and modify behavior. Correct?

Customise the interface, no. Customise certain interoperation points, yes. Like when an outcome gets constructed into a result, you can specify how that should be per-namespace.

You are considering shipping Outcome v2 with one such customized type that resembles Expected as close as possible in order to: 1. Demonstrate that this is possible 2. Because many people will want to use a type they have learned from reading proposals for Expected.

It's already shipping an Expected implementation, but in its test suite purely so I can reuse Vicente's Expected test suite. Perhaps the FAQ entry might help? https://ned14.github.io/outcome/faq/#how-far-away-from-the-proposed-std-expe... But to answer your question, for v1 Outcome lots of people wanted an Expected implementation, not anything Outcome is doing. But v2 Outcome is much closer to Expected than before, and moreover the Expected proposal itself moved much closer to Outcome thanks to the Outcome v1 review. See https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r3... for just how much closer. I was just wondering how important an Expected implementation remains for people. Outcome v2's `unchecked` and `checked` are awfully close to Expected, as the draft WG21 paper comparing Outcome and Expected shows (https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ynDjm5t1U_k/oYtlp...). Is it desirable that Outcome makes an Expected implementation a first tier type, or better to leave it to an FAQ entry like at present? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

It's already shipping an Expected implementation, but in its test suite purely so I can reuse Vicente's Expected test suite. My implemtation is not so good to go to Boost ;-) Some of my test can be good, maybe others are not. In anycase I'm not sure they are sufficient :(

I'm always very wary of trusting tests that I write myself. I consistently find that I end up missing things. A good test strategy is to use someone else's tests with a compatibility shim, it exercises parts I would never have thought of. BTW your test suite did find new bugs, but interestingly in one of the C++ compilers, not in Outcome :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/