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 08:44:20

czw., 13 wrz 2018 o 10:11 Mike Dev via Boost <boost_at_[hidden]>

> OK, so my 2 cent on this as a pure outside user of boost:
> Whatever else, I agree with Andrzej, that the default policy should not
> change
> from throwing to UB depending on the EC type. If I don't explicitly change
> the
> policy I don't expect the overall behavior to change. A throwing default
> seems
> to be the best choice as it also matches the behavior of e.g.
> std::optional::value
> and thus probably matches the expectation of most people not familiar with
> boost outcome. If outcome can't generate such a behavior, e.g. due to a
> missing
> customization point for the translation from error type to exception, then
> a compilation error seems more reasonably to me than a "silent decay" to
> UB.
> Just to be clear: that doesn't mean, I'm not very happy that I can
> customize
> the behavior into UB to improve performance and codegen. I agree with
> niall,
> that this is a very important aspect of outcome.
> To comment on another aspect raised by Andrzej:
> Personally I'm in the camp that "value() on value less" is a logic error
> and *foo().value()* should not become an idiom for "return the value or
> throw",
> even if the policy chosen for that particular version of result does allow
> it.
> I think, that if the developer wants to express a "return the value or
> throw",
> semantic, there should be a specialized function for that ( e.g.
> value_or_throw())
> that does exactly that, independent of a particular policy type being
> chosen,
> because that decision should be local to a particular call site rather than
> being general to
> general.

That would be my ideal preference also: value() is narrow-contract (a bug
if you call it for valueless), and for the idiom "value or throw" use
`foo().native()`, where "native" reads as "switch to system's native error

> Of course I'm saying this knowing full well that the design phase of
> outcome
> is over and that std::optional::value() (and related) may already have set
> the
> road for the *foo().value()* idiom. I just felt the need to express my
> general
> view on this here. The important part is at the beginning of this mail:

I also agree here that it might not be feasible anymore.


> The default policy should not "silently decay"!
> Best
> Mike
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at