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

Subject: Re: [boost] [variant2] Andrzej's review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-13 22:49:37

On Sat, Apr 13, 2019 at 3:14 PM Niall Douglas via Boost <
boost_at_[hidden]> wrote:
>
> >> What I specifically meant was "worse-than-useless choice of
> >> implementation by variant2 of the basic guarantee which is only
> >> technically valid, but is certainly surprising".
> >
> > I'll repeat myself, I fail to see any logic in this statement that
doesn't
> > apply to std::vector::op=.
> >
> > Yes, with variant2 the contained type may change, whereas the type of
the
> > objects in the vector won't change, but this is irrelevant. It's like
> > saying well, at least variant won't change its size, whereas a vector
> > could, and that is "technically valid but is certainly surprising".
> >
> > Yes indeed, when an error occurs, you might find objects in a state that
> > you didn't set explicitly. Being surprised that the state may change is
> > equivalent to not understanding how error handling works under the basic
> > guarantee.
>
> The problem is the hard coding of random change of state on exception
> throw during assignment. Yes, a vector may be in some weird state after
> an exception throw middle of operator=.

The state is not weird, in fact it is guaranteed to be valid.

> But that's on you for your
> choice of T in vector<T>. It's not hard coded into vector's design as a
> default, so it's imposed on all users of vector.

Yes it is very much in the vector design. Someone correct me if I'm wrong,
but my understanding is that a conforming implementation of
vector<int>::op= may first free the currently allocated memory, then fail
to allocate. The state of the object will change, and this has nothing to
do with int, everything to do with the basic guarantee.

In addition, could you clarify how is the choice of T in vector<T>
different than the choice of T and U in variant<T, U>? After all,
variant2::variant<int, char>::op= can't fail.