Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?

czw., 13 wrz 2018 o 01:26 Emil Dotchevski via Boost napisał(a):

On Wed, Sep 12, 2018 at 3:25 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

czw., 13 wrz 2018 o 00:18 Peter Dimov via Boost napisał(a):

...

Andrzej Krzemienski wrote:

...

You have just described something that one could call "value or throw" idiom: `foo().value()`. It will only work under certain policies: [...]

The basic point here is that "value or throw" or "value, period" are used in different ways. One is

auto r = function().value();

and the other is

auto r = function();

if( r ) { // use the value of `r` }

Since the two forms are distinct, it doesn't really make sense to express both using the same name because then you can't tell at a glance whether the code is correct or not.

Yes, they are two distinct cases. And yes, they should probably be expressed in two different ways.

My understading was that initally Outcome attempted, in part, to be an easy solution to this problem (building interfaces which return value-or-throw results).

I am not sure if we mean the same thing. Do you mean the "dual" interfaces like in filesystem, when nearly each function has two overloads? If so yes: this was one of the goals of Outcome, it still is, and I think this case is handled successfully. This is of course a personal opinion.

It appears that this functionality is now deeply burried in policies and other complexity (assuming it still exists, which is still unclear to me).

I would not agree with this characterization. It is assumed that the most natural choice for `EC` would be `error_code`. The type the user would use is `result<T>` (second and third parameter defaulted), and the `fun().value()` idiom that you described works out of the box. If the user wants her custom `EC` (other than an enum plugged into error_code framework), under my proposed change, she will get a compiler error with instructions how to make her type work. She has to make a choice what exception to throw: * provide er own exception * decide to go with the default exception type that comes with Outcome The UB policies that were mentioned in this thread, would have to be requested explicitly by the user.

I assume this is driven by pressure from users who don't want to use exceptions at all.

In part, probably so. If I work in a no-exceptions environment, and want to use `result<>` with my custom error type, and I do not want to think "which type of exception to throw". UB polict or call-abort policy seems fine.

If someone is building an API that simply needs to return value-or-throw results, would Outcome be the recommended provider of this functionality?

That would be my personal preference. As to general recommendations, I do not feel sufficiently qualified to answer this question. Outcome requires C++14 features, so it would be a no non-recommendation for libraries that need to support older standards.

Is there even a single example of such a library that uses Outcome?

This would be best answered by Niall. Regards, &rzej;