|
Boost : |
Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-09-13 07:03:41
czw., 13 wrz 2018 o 01:52 Gavin Lambert via Boost <boost_at_[hidden]>
napisaÅ(a):
> On 13/09/2018 09:48, Andrzej Krzemienski wrote:
> > template <typename T>
> > using resultC = result<T, MyErrorCode>;
> > // the above will be *UB* on value from valueless, because default_policy
> > is UB for unknown (to the framework) types.
> >
> > The fourth case is described as it works today. The proposal in this
> thread
> > is to change the fourth case so that default_policy fails to compile when
> > used for unknown types.
>
> That seems sensible to me.
>
> In my view it is always superior to choose fail-to-compile over UB
> whenever possible, at least for obviously silly code. And "quietly"
> switching from throw semantics to UB is probably not a good idea, as you
> pointed out.
>
>
> *Having said that*, if I'm understanding correctly, this sounds like it
> would mean that you won't be able to use a custom error_type with
> Outcome unless you either:
>
> 1. Declare some "this is how you throw an exception for this
> error_type" method (presumably a template specialisation?)
>
> 2. Only ever use it with some non-default policy (that either never
> throws or has user-implemented code to throw).
>
> Is that correct? (Or would #1 always be required regardless of usage?)
>
> If so, while I'm not sure whether that's enough to change my mind, it
> does make me a little hesitant about adding another hurdle.
>
>
> On the *other* other hand, it wouldn't be a silly idea to have a generic
> "throw this error_type" method. system_error itself was somewhat trying
> to be that generic method, but with the caveat of only supporting plain
> enum error_types.
>
> Perhaps boost::throw_error, which is expected to internally construct an
> appropriate exception based on its argument type and then call
> boost::throw_exception?
>
This is actually what Outcome is currently doing (modulo the unfortunate UB
case in the default policy). For the sake of keeping this discussion
focused, I did not describe the the full behavior of the default policy,
which is:
+ Throw system error when `EC` is:
* error_code
* an enum "plugged" into the error_code framework
* a type for which ADL can find function make_error_code() that converts
it to error_code
+ if `EC` is exception_ptr, rethrow the contained exception
- If `EC` is void call std::terminate
- otherwise UB
The last two (marked with `-`) are the ones that I would propose to change.
And Outcome is also using an ADL-based customization point
outcome_throw_as_system_error_with_payload(), which gets an `EC` and throws
the desired exception (quite similar to what Peter suggests).
Regards,
&rzej;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk