2018-02-02 4:58 GMT+01:00 Emil Dotchevski via Boost
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;