wt., 16 kwi 2019 o 19:07 Emil Dotchevski via Boost
On Tue, Apr 16, 2019 at 4:19 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
But we do, std::variant does in fact have checks.
I guess you are referring to function std::visit(), which checks for valueless_by_exception state and if one is detected throws an exception.
https://github.com/llvm-mirror/libcxx/blob/master/include/variant
I counted 20+ checks, but actually even if the runtime cost was zero, the empty state is one more thing the user has to think about, one more thing that could go wrong -- but only in the context of error handling where writing unit tests, debugging and QA are all extra difficult.
In my point of view (obviously, we disagree in some aspects) your statement above mixes very valid observations with one invalid statement. I agree that exception handling paths are very difficult to design and test. I agree that the majority of the bugs lurks in these paths. However, I disagree that a solution for these paths would be to mask bugs, as opposed to bringing them as clearly as possible to programmer's attention. By "masking" I mean making the consequences of bugs well defined semantics according to the rules of the abstract machine, and letting the program continue and do unpredictable things (possibly causing UB in other places). This is what I see when boost::variant default-constructs a type of its choice upon exception.
Indeed, in the model that I am presenting, this is a useless check.
The world without the basic guarantee and without checks does not exist.
I think it is unfair to use this words, after I tried to clarify the concepts (even if you disagree with the concepts). What I try to explore is functions that do provide basic guarantee, in types that have invariants weaker than what you would expect. But it is still a basic guarantee. What I am proposing is that "basic guarantee" and "not having to do the checks" are not synonymous. And my understanding of your comments is that you treat the two as synonymous.
The user will be finding bugs, sooner or later he'll be calling functions when he shouldn't, and he'll add the checks that you say he doesn't need.
You seem to be saying that we will have incorrect programs that use types
incorrectly. I agree. I addressed this in reply to Peter.
That said, I agree that the checks are lame. If I say variant
say but you also have to deal with C, I'd say the design is broken.
Thank you for raising this. Indeed I think we think alike in many aspects: strong invariants, no tiresome repetitive defensive checks. It is only this particular case of the variant that we disagree with. ANd maybe there will be no disagreement if peter goes with "semi strong" guarantee. Regards, &rzej;