Boost logo

Boost :

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-09-12 23:51:47


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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk