Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-04 00:26:43
On Tue, Apr 2, 2019 at 7:07 PM Gavin Lambert via Boost <
> On 3/04/2019 13:38, Emil Dotchevski wrote:
> > The problem with explicitly testing is that it must be done everywhere
> > because we don't know if maybe we are being called from an
> > context (note, this doesn't necessarily mean exception handling). For
> > example, every member function must check if the class invariants are in
> > place for *this (assuming UB is not acceptable).
> How is this different if the instance can be empty, or can unexpectedly
> change from type A to type B?
> If you don't know whether you're handling an errored instance or not,
> then it could be unexpectedly empty (with one variant implementation) or
> it could be unexpectedly type B (with another implementation). I don't
> see any practical difference between these cases.
Consistent with the basic guarantee, if you assign one std::vector to
another and the copy operation fails, the contents of the target vector is
not specified, but it is guaranteed to be a valid vector, so that if you
happen to handle it later, you can safely do with it what you do with any
other vector: you can insert or delete elements, iterate, whatever.
By analogy with your position, a better design for std::vector would be to
define a special "error" state that you must check for *every* time you
handle a vector, and the justification for that design is that otherwise it
might be unexpected to see a vector in a half-copied (but valid, by
definition) state. Do you see the practical difference now?
Going back to variant, in one case, we are defining an empty state, which
forces the user to provide explicit handling for that state, *everywhere*.
Otherwise, we are not defining an empty state, and the user doesn't have to
provide special handling, *anywhere*, because he doesn't have to care that
A "unexpectedly" changed into B. He sees a B, he does what he normally does
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk