Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-14 22:54:23

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.)