czw., 13 wrz 2018 o 09:18 Alexander Grund via Boost
My 2 cents: The unexpected is always bad, so value() should NEVER be UB.
I think I like your suggestion even better than what is being proposed in this thread. We would then have: * `value()` has always wide contract, and it is not "defensive", it is a useful idiom: switch to system's native error reporting. * `assume_value()` has always narrow contract: the user takes responsibility for never invoking it on valueless objects.
The arguments already came:
auto r = function().value();
and the other is
auto r = function();
if( r ) { // use the value of `r` }
Together with In the present Outcome you have both `value()` and `assume_value()`. In the default policy, with default `EC` the former throws and the latter is UB, but this is in general subject to policy, and if you are nasty, you can actually configure them the other way around, I think. So you have `value()` for the 1st case which throws on valueless and `assume_value()` which UBs on valueless.
Given that, the policy should only be there to decide WHAT exception to throw and fail to compile for user-defined error types.
Well, throwing an exception is not the only reasonable choice here. For instance, some people use the STL compiled in -no-exceptions mode. In such case, in any place where normally an exception would be thrown, function `abort()` is called instead. For uniformity, these users might expect Outcome to also call `abort()`. `abort()` is not an UB: it is predictable, and drastic as it is, it can still be considered as means of handling errors. For instance in a video game: if it occasionally crashes, it is acceptable. The policy might
also NOT define any exception throwing in which case `value()` should be unusable (compile error on use). This would make sense if you don't allow any exceptions in your code and are always using the 2nd use case instead. Note that the actual "throw" has to be in library code so no one can accidentally create a policy that does not throw.
The "value() always wide, assume_value() always narrow" solution appears very clear and easy to explain, however it might turn to be not acceptable for social reasons. Name `value()` sounds attractive and users want to use it by default: both the users that compile with no-exceptions, and the users who wan to us exceptions and the `fun().value()` idiom. Regards, &rzej;
In any case: Even keeping the current design there should NOT be an automatic switch to UB. But as detailed above overloading the _semantics_ of `value()` is surprising and therefore bad.
Regard, Alex
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost