On 12/05/2017 04:19, charleyb123 wrote:
The formal review of Niall Douglas' Outcome library starts next week (Fri-19-May to Sun-28-May). [...] - What is your evaluation of the documentation?
During a quick skim through the docs: in "Expected<T, E> in Practice" section "The tension between type safety and convenient programming", it's unclear why the final example is any "better" than the ones preceding it. In particular, if you're going to explicitly add a constructor to MathError2 such that it knows how to construct itself from MathError1 (as in the final example), why would you not put the switch statement from the first example into that constructor, such that it actually translates the error codes into the expected domain? Especially when there is no loss or overlap in doing so, as in these examples? Granted std::error_code does let you transport "foreign" error codes, but surely translating recognised codes from a method's internal implementation to those of its external interface is desirable? (Though perhaps that may depend somewhat on your views of encapsulation and implementation hiding.)