Boost logo

Boost :

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-09-13 07:22:09


czw., 13 wrz 2018 o 01:26 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> On Wed, Sep 12, 2018 at 3:25 PM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> > czw., 13 wrz 2018 o 00:18 Peter Dimov via Boost <boost_at_[hidden]>
> > 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;


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