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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-09-13 07:59:14

czw., 13 wrz 2018 o 09:18 Alexander Grund via Boost <boost_at_[hidden]>
napisał(a):

> 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
>