Re: [boost] [variant] Please vote for behavior (Was: Basic rvalueand C++11 features seupport)

Subject: Re: [boost] [variant] Please vote for behavior (Was: Basic rvalueand C++11 features seupport)
From: Louis Dionne (louis.dionne92_at_[hidden])
Date: 2013-01-21 17:10:50

Peter Dimov <lists <at> pdimov.com> writes:

>
> Louis Dionne wrote:
> > My vote goes to II.
> >
> >     - Using moved-from objects should rarely happen, if ever.
> >     - It is not even a breaking change since move from variants was not
> >       supported in the past.
>
> That's not quite true. If a type doesn't have a move constructor, move is
> supported and same as copy.

At first, I thought using proposition II would introduce a breaking change.
After reading Joel de Guzman's post, I learned this was not the case. What I
meant is that we don't run the risk of breaking existing code, which is one
less reason of not adopting proposition II. Still, thanks for the precision.

> > [snip]
>
> I fail to grasp the logic that simultaneously holds that
>
> >     - Using moved-from objects should rarely happen, if ever.
>
> and then proceeds to argue that moved-from objects should not be left in
> such-and-such valid state, but must be left in an invalid state instead.

In my post, I assume that the rare situations in which a moved-from variant
is used are programming errors. In such case, I would definitely prefer the
variant to be in an invalid state and to get an assertion ASAP so I can fix
my code.

With proposition III, using a moved-from variant implies that you know what's
in it after the move, i.e. the type of the held object and the fact that it is
default constructed. In such case, it is equivalent to create a default
constructed object of that type and to use it instead.

With proposition II, using a moved-from variant is just a no-no. You can
create a default constructed instance of the type you want if you need to
instead of relying on the implicit behavior of the moved-from variant.

The above assumes that the variant types contain a recursive_wrapper.

Best,

Louis Dionne