Re: [boost] [proposal] raw move

Subject: Re: [boost] [proposal] raw move
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-24 16:03:54

Dave Abrahams wrote:

> Destructive move is practically impossible to manage regardless of
> exceptions:
> 
>        void f()
>        {
>            SomeType x;
> 
>            if (some_condition)
>            {
>                something_that_moves(x)
>            }
>            else
>            {
>                x.foo()
>            }
>            // Do we call x's destructor?
>        }

After your email that explained the practical equivalence of 
destructive moves with raw moves, I find this example illuminating 
because it shows a problem that doesn't apply to raw moves.

Suppose that the example concerns raw moves instead of destructive 
moves. In that case there is no choice at the end of f(): x' 
destructor will be called regardless of the truth value of 
some_condition. Furthermore we can assume that the code is 
unproblematic because we trust the author of something_that_moves.

Either:

something_that_moves(x) returns with x being in an invalid state,

in which case the author has violated the rule that chains of raw 
moves bust be closed within the same scope;

Or:

something_that_moves(x) properly closes its internal chain of raw 
moves,

in which case x is in a destructible state after function exit and 
there is no problem.

So the conceptual difference is that in destructive moves, it is the 
compiler's responsibility to maintain integrity, while in raw moves it 
is the programmer's responsibility. For programmers there are clear, 
strict rules* for avoiding invalid destruction of raw-moved objects. 
If we treat raw moves as if they are the compiler's responsibility 
instead, they seem intractible.

-Julian

* 1) Once a chain of raw moves starts, in has to finish within the 
same scope; 2) all operations between the start and the end of a chain 
of raw moves must be non-throwing. I don't think there are more rules, 
but there might be.