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