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.