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
> from throwing to UB depending on the EC type. If I don't explicitly change
> policy I don't expect the overall behavior to change. A throwing default
> to be the best choice as it also matches the behavior of e.g.
> 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
> customization point for the translation from error type to exception, then
> a compilation error seems more reasonably to me than a "silent decay" to
> Just to be clear: that doesn't mean, I'm not very happy that I can
> the behavior into UB to improve performance and codegen. I agree with
> 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
> even if the policy chosen for that particular version of result does allow
> I think, that if the developer wants to express a "return the value or
> semantic, there should be a specialized function for that ( e.g.
> that does exactly that, independent of a particular policy type being
> because that decision should be local to a particular call site rather than
> being general to
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
> is over and that std::optional::value() (and related) may already have set
> road for the *foo().value()* idiom. I just felt the need to express my
> 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"!
> Unsubscribe & other changes: