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-13 01:58:01

On 13/09/2018 12:54, Peter Dimov wrote:
> However, I vaguely remember that I convinced myself at one point that 
> the latter (calling a function to convert) is inferior to calling a 
> function that throws. For one thing, you can't convert an exception_ptr 
> to an exception (*); for another, sometimes you want to throw different 
> exceptions based on the runtime value of the error code (bad_alloc on 
> ENOMEM for instance.)

True.  I did start writing the email that way, but along the way thought 
that it might be a good idea to require use of boost::throw_exception 
via a return value (and thus getting a return-type trait for "free").

But you're right that there are some cases that don't work as well that 
way, since value returns aren't polymorphic.

> (*) This is needed, for instance, when you build an outcome<> on top of 
> a result<> by
> 
> struct my_error_code
> {
>  Â Â  std::error_code code_;
>  Â Â  std::exception_ptr exc_;
> };
> 
> template<class T> using outcome = result<T, my_error_code>;

Arguably that sort of construction ought to "unpack" the error into the 
three-type outcome<T, my_error_code_without_exception, exception_ptr>. 
Other than interop with pre-Outcome code I would think that such cases 
should be fairly rare.