Boost logo

Boost :

Subject: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-09-13 08:11:32


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.

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:

The default policy should not "silently decay"!

Best

Mike


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