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. I think this misses the point of the outcome library: You want to return either a value or an error. As the caller you cannot know whether the outcome is a value or not, so yes calling value() on that w/o checking is an error. This leads to code like `if(result) result.value().use()`, otherwise it is a logic error. Would you agree with this?
If this is the case: The throw code on `value()` will be completely removed by the compiler as being always false due to the `if(result)` before. If you do defer (for some reason I cannot imagine) the `value()` call far enough away from the if-check, so that you fear the compiler may not know this anymore, you can always use `assume_value()` with hard UB and no exceptions. This achieves 3 things: - The easy road is the safe road (accessing `value()` will either return the value or throw/terminate) - No overhead for correct usage (throw and 2nd check eliminated by compiler) - Explicit unsafe use (longer and explicit name for `assume_value()`)