2017-05-28 0:45 GMT+02:00 Peter Dimov via Boost <boost@lists.boost.org>:
Andrzej Krzemienski wrote:
But tell me this. Consider the example with class Man above:
``` struct Man { std::string fist_name, last_name; }; Man m1 = {"April", "Jones"}; Man m2 = {"Theresa", "May"};
try { m2 = m1; // suppose it throws } catch(...) { } ```
Object m2 after recovering from stack unwinding may be in the state {"April", "May"}, which is a "valid state". Would you call it a valid state?
It depends on the invariant of Man. Assuming no invariant, yes, it's valid. It doesn't crash if I access it.
Same with outcome<T>: if I assign to it and it fails:
o1 = o2; // assume basic guarantee
provided I get transactional guarantee, I know what its value is. But if I get "basic guarantee" as you describe it (valid but unspecfied state), what good does it make that I can safely call has_value() if the object contains a different value than o1 or o2 had initially?
What good it makes is that you can call has_value() on it without crashing.
Without this guarantee, you could never safely call has_value() on a foreign object without checking valueless() first.
Hold on. I am talking about "valueless_by_exception" which cannot happen for just any reason: only when you tried to mutate the object and it threw an exception in the middle. I am not talking about a default constructed state. I get the result from the function: ``` expected<T, E> o = fun(); // (*) if (o.has_value()) ... ``` Upon the call to has_value() how is it possible that I am experiencing the valueless_by_exception state? Either I was trying to assign a different value in between (what I marked with (*)) and caught exception (in which case I am doing something fishy), or function fun() is already returning a valueless_by_exception, but why? because it inside again is assigning, and try-catching the assignment, which again is fishy. IOW, my claim is that if in your code you have concerns whetherr calling has_value is safe in the face of valueless_by_exception, you are doing something wrong (catching exceptions prematurely). Rgards, &rzej;