Re: [boost] Outcome/expected/etc/etc/etc

Subject: Re: [boost] Outcome/expected/etc/etc/etc
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-05 14:39:45

Gottlob Frege wrote:

> So converting a Circle to a Triangle might result in a Rectangle, because 
> Rectangle is the fallback?

If an exception is thrown, yes. That's how the basic guarantee works. 
"Converting" from a vector with 5 elements to a vector with three elements 
may result in a vector with zero elements on failure, and "converting" from 
a Circle to a Circle may result in a Circle that is neither of those two.

I argued that variant's assignment should provide the strong guarantee, as 
the usual idiom of copy+swap that is used for other types doesn't work for 
variant, but was persuaded that it in fact does, in the final wording. I 
have to verify whether this holds in my implementation, and under what 
conditions.

> I'd rather have double buffering or valueless_by_exception.  ie 
> correctness or acknowledgement of error.  Not silent incorrectness.

It's your prerogative to be wrong. :-)

> Why not add "throw E if derived from std::exception" as part of that 
> fallback?  It is probably what users want.(?)

This would imply that expected<> would be used to return types derived from 
std::exception, and I don't see this as common. Although with that said, 
yes, it would be easy to add that as part of the default behavior if there's 
demand for it.

It would open the door to the subsequent question of whether it ought to be 
possible to override the behavior for a whole hierarchy rooted in a user 
class in a similar manner, though, which would imply that the default would 
need to be made a worse match in some way. There are pros and cons for that.