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/