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 19:18:44

On Thu, Sep 13, 2018 at 11:52 AM Emil Dotchevski <emildotchevski_at_[hidden]>
wrote:

> 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.
>

I mispoke, please disregard the above.