2017-05-30 15:18 GMT+02:00 Niall Douglas via Boost
FWIW, my preferred options would be (which I think were the originals):
- value() throws if holding error or exception (or empty)
- error() returns E{} if holding value or E{errc::has_exception} if holding exception, or E{errc::no_value} if empty (names made up on the spot, doesn't matter)
The current behaviour is "always throw on observing empty". That's what makes empty special (and it traps unintentional propagation of empty).
- exception() returns nullptr if holding value or error or empty
The current behaviour is to return null exception_ptr if valued (so if(eptr) would be false i.e. "no exception here"), std::make_exception_ptr(std::system_error(error())) if errored, throw on empty.
So an errored state is also an excepted state, but an excepted state is never an errored state. has_exception() returns true for either errored or excepted states.
But is there some mental model behind this decision?
std::make_exception_ptr(std::system_error(error())) is fairly cheap, a few thousand CPU cycles. std::exception_ptr's are heavy anyway.
Or are these decisions, what to return in tricky cases are only driven by performance? Regards, &rzej;