Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-02-02 07:49:42

2018-02-02 4:58 GMT+01:00 Emil Dotchevski via Boost <boost_at_[hidden]>:

>
> Ideally, the erorr type should be erased, that is, it should not be a
> parameter of the result template, but of the result constructor, so that
> error-neutral contexts can just forward _any_ error to the caller. This is
> not easy to do. I tried to do this, but the result<T> type I ended up with
> wasn't efficient enough to return at every function call. This lead me to
> the realization that it's a bit silly to return the error object one level
> at a time, because usually the caller only needs it to return it to its
> caller. Ultimately, this lead me to using TLS, and the result is (Boost)
> Noexcept.
>

I agree practically with everything you say, except for the above
paragraph. That is, in most applications, in most parts the situation is
exactly as you describe: what you want to do is to forward the failure
reason up and abort the current task. And you would look for solution where
this is done by default.

In contrast, Boost.Outcome is intended for usage in these rare cases were
"forward up and abort" is not the thing you would like to do most of the
time. Its goal is not to handle failures anywhere, but to solve a specific
problem in specific places. I believe that the criticism of Boost.Outcome
should be in this context of places where "forward up and abort" is not
what you typically need to do.

Regards,
&rzej;