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