Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk