I am trying to summarize differences between `expected` and `result<T>`. So far, I have identified the following:

Sorry I didn't answer this earlier. I've been trying to reply to the short emails and bug reports early and deal with the longer replies on a first received first replied basis. I missed this one.

1. API/ABI stability guarantees.

Yes.

2. `result` has empty state - `expected` does not.

*Formal* empty state. Yes.

3. `result` uses error_code_extended for more error details in the ring-buffer.

result and outcome hard code E to error_code_extended. expected defaults E to error_code. You can, of course, manually supply error_code_extended as E to expected.

4. No ordering (operator<) for `result`

No, nothing gets ordering operators. It is unsafe to combine ordering operators with implicit conversion according to your own blog!

Is the above list complete?

No, result has a wide contract on all its member functions such that you can never achieve undefined behaviour. That's those woolly "default actions" previously discussed. expected implements operator*, operator->, .error() etc as reinterpret_cast. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/