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

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2018-09-13 18:52:54

On Thu, Sep 13, 2018 at 12:22 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> 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:
> >
> > 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)

I don't understand why are we talking about error codes in this context.
The use case I'm talking about does not use error codes, its only way to
report an error is to throw an exception, it's just that the throw is
postponed until value() is called.

And my other question was, are we sure that anyone is using Outcome for
this use case. If the answer approaches "no", that is, if nearly all users
of Outcome use it only to design exception-free interfaces, it might be
better to provide this functionality in a different library.