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

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