2017-05-31 14:43 GMT+02:00 Niall Douglas via Boost
On 31/05/2017 00:43, Gavin Lambert via Boost wrote:
On 31/05/2017 01:18, Niall Douglas wrote:
The current behaviour is "always throw on observing empty". That's what makes empty special (and it traps unintentional propagation of empty).
That makes sense when empty is always "you forgot to return a value". However you've said yourself that sometimes you've hijacked it as an intentional return of no value (as in optional<T>), and that's where things get murkier.
You do realise there is nothing stopping a person using the valued state to return an error, the errored state to return a value, and the excepted state to return a type erased smart pointer?
That is of course true, but no-one has ever brought such obviously invalid (or at least confusing/hackish) use cases.
Empty state is no different.
The difference is that you have brought it up as an example of where the empty state could be used in practice. In the code written by the author of Boost.Outcome. This is easily taken as usage recommendation. This is the message I got form reading your replies: It is easy to implement and use `outcome` without an empty state in the interface, but without empty state, the use case from AFIO would not work. This is about the only use case you have shown us. I am not saying that you have said that explicitly. This is simply my impression after reading all the posts that mentioned the subject.
- 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.
std::make_exception_ptr(std::system_error(error())) is fairly cheap, a few thousand CPU cycles. std::exception_ptr's are heavy anyway.
I can understand that, but I'm not sure I can entirely agree with it. As previously mentioned an error_code return is supposed to indicate a non-exceptional error, while an exception is exceptional. So this feels like promoting a non-serious error to a serious error.
Sure. But this semantic also means that errors don't get accidentally lost if the programmer checks for an exception without checking for an error. I figured that to be a safer default.
So this is to prevent accidental user bugs? Or rather the consequence of the mental model where "error" means either error_code or exception_ptr? Regards, &rzej;