Re: [boost] [variant2] Andrzej's review -- design

Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-07 19:40:36

On Sun, Apr 7, 2019 at 1:38 AM Rainer Deyke via Boost <boost_at_[hidden]>
wrote:
>
> On 06.04.19 21:24, Emil Dotchevski via Boost wrote:
> > I get what you're saying, that if an assignment fails, logically you
wish
> > to treat the resulting state something like an uninitialized state. The
> > problem is that your program can no longer assume that all objects it
works
> > with are valid -- that is, RAII is out the window -- except if the
special
> > state is (by definition) a valid state. But this contradicts your wish,
> > because a valid state is nothing like an uninitialized state. It has to
be
> > on your mind all the time, because now objects in this state are valid
(by
> > definition) and you must define behavior for functions that are handed
such
> > objects.
>
> You keep using the term "valid" as if its a clear-cut binary
> distinction.

Do you see that this is a matter of definition? I use the common
definition: "valid" is equivalent to "the type invariants are in place". It
seems that by your definition, for an object to be valid, it is not
sufficient that the type invariants are in place.

Under the common definition, if two states A and B fit the invariant
constraints of the type, it is illogical to rank the validity of A and B.
Both are perfectly good states, by definition.

Stronger: to argue that either A or B is an invalid state is equivalent to
arguing that the basic guarantee may leave the program in an invalid state.
This is nonsense, the whole point of the basic guarantee is to guarantee
that the state is valid.

> However, I can think of at least four different degrees of
> validity:
>
> 1: Garbage. A variable (of a class type) was not properly constructed
> and contains complete garbage.  It is undefined behavior to perform any
> operation on the object, including assignment and destruction.
>
> 2: Uninitialized. A variable (of a built-in type) is uninitialized.  It
> is undefined behavior to read the value of this variable, but the
> variable is "valid" in the sense that you can assign a new value to it
> and that you can destruct it.
>
> 3: Indeterminate.  A variable (of a class type) has an indeterminate,
> semantically meaningless state (after throwing an exception from a
> member function with the basic exception guarantee, or after being
> pulled from an object pool).  It is technically allowed by not
> semantically meaningful to read the value of this variable, but the
> variable is "valid" in the sense that you can assign a new value to it
> and that you can destruct it.
>
> 4: Correct.  A variable (of any type) is valid and contains a
> semantically meaningful and correct value.
>
>
> You seem to categorize degrees 3 and 4 as "valid" and degrees 1 and 2 as
> "invalid".

I'm using existing, well established definitions. C++ is not defined in
terms of the above degrees of validity, and it does not make a distinction
between 3 and 4. If 3 and 4 are the same thing and a new "empty" state is
introduced, by definition it must be a valid state, which (I argue) weakens
the type invariants and therefore complicates all operations, for no good
reason (because a valid state is a valid state).