Re: [boost] [review] Boost.Outcome.v2 Review Report

Subject: Re: [boost] [review] Boost.Outcome.v2 Review Report
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-02-05 08:19:21

2018-02-05 3:16 GMT+01:00 charleyb123 . via Boost <boost_at_[hidden]>:

> # Boost.Outcome.v2 REVIEW REPORT
>
> In conclusion to the review for Boost.Outcome(v2) (19-Jan to 28-Jan, 2018):
>  The library is ACCEPTED (conditions below).
>

Wow. Congratulations Niall for getting Outcome accepted into Boost. But at
this point I would really like to congratulate Charley on managing the
review and coming with the verdict. It is my perception that this review
was particularly hard and controversial. One can learn a lot only from
reading the justification of the verdict.

The beclouded discussion appeared at times to exhibit violent agreement:
>
> Quoting reviewer (voting to reject):
>   > However it looks like Outcome provides a solution for most of the
> practical
>   > cases, while leaving the general case unsolved. Boost.Outcome is a set
> of
>   > tools (rather than just one) and you are expected to choose one that
> best
>   > solves your particular problem.
>
> Quoting response by library author:
>   > I was just about to say the same thing, but more pointed.  <...>
> Knowing that
>   > a piece of code will never, ever see stack unwinding lets you skip
> handling
>   > stack unwinding. Hence `noexcept`.
>   >
>   > Furthermore, unlike with exception specifications which were
> unhelpfully checked
>   > at runtime, Outcome fails at compile time. .... You can't successfully
> compile code
>   > if your E types don't have interop specified for them.
>   >
>   > Outcome is of particular use in a lower-level layer of code (closer to
> bare metal,
>   > or in server contexts), where explicit deterministic error handling
> warrants
>   > increased tedium or inconvenience in explicit checks for
> success/failure.
>

I would like to clarify one thing. In the quoted discussion above it was
actually me talking to Niall, and I voted to conditionally accept the
library. It does not change the conclusion though, as indeed there were
points in the discussion where those voting to reject did agree on the
scope and limitations of the library.

Regards,
&rzej;