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

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-09-13 08:21:36

> 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()`)