Re: [boost] auto_vector - vector with auto_ptr semantics

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-02-04 19:40:24

On Monday, February 4, 2002, at 06:27  PM, Jeremy Siek wrote:

>
> Nice description and motivation for move semantics.
>
> On Mon, 4 Feb 2002, Howard Hinnant wrote:
> hinnan>
> hinnan> What remains to be done is to settle on a uniform syntax for 
> move
> hinnan> semantics.  John Maddock has suggested:
> hinnan>
> hinnan> T b = std::move(a);
>
> Would this mean we'd also have to rely on cooperation from operator=?

John Maddock has suggested that std::move return the struct 
std::move_t<T>.  Then the class T could create a constructor and 
assignment operator that accepted a std::move_t<T>.  This has a nice 
parallel with the current requirements of implementing copy semantics.

> Wouldn't it be better to keep things simple with something like this
> instead:
>
> std::move(a, b);  // a -> b

I'm open to just about anything!

> hinnan> Perhaps boost::auto_vector could experiment with this.  The big
> hinnan> stumbling block I've had to date is allowing move from a 
> temporary T,
> hinnan> but disallowing move from a const T, and packaging this up in a
> hinnan> relatively reusable package so that giving your class move 
> semantics is
> hinnan> no harder than giving it copy semantics.
>
> Well, non-const member functions have the property that you can call 
> them
> on temporaries but not on const objects. So you could do this:
>
> a.move_to(b);
>
> Of course, this would require invasive changes to current classes, and
> couldn't have the same syntax for builtins.

I think invasive changes to current classes is unavoidable.  Only vector 
knows how to move itself.  About the only (std) classes (with 
non-trivial move) that everyone already knows how to move is list 
(splice) and auto_ptr (copy).

And your point about builtins (scalars) is right on the mark.  We *must* 
have the same move syntax for scalars, and that can be implemented as a 
copy.  Without the same syntax for scalars, templated code wanting to 
move goes out the window.

And on the subject of templated code using move:  The code must be able 
to determine if the template type supports move semantics.  John Maddock 
to the rescue again, (with significant help from Andrei Alexandrescu) 
has suggested:  Use is_convertible to discover if a std::move_t<T> will 
convert to T (via T's converting constructor taking a std::move_t<T>).  
And a rule that says if you support move construction, you must also 
support move assignment.

On the other hand, if we can detect the presence of move semantics, then 
scalars could be defined to not support move, and thus move syntax need 
not accommodate scalars.  A design worth exploring...

> Or perhaps we just need to file a DR to once again allow temporaries to 
> be
> bound to non-const references. On the surface that restriction made a 
> lot
> of sense, but deep down it was wrong.

I would be against such a DR.  But I would be violently in favor of a 
language change that allowed a method to detect the difference between a 
temporary parameter and a const parameter.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#214 comes 
tantalizingly close in sub-issue 2:

     template<class T> void g(T);  // #1
     template<class T> void g(T&); // #2

If this were allowed, temporaries would bind to g(T), non-const lvalues 
would bind to g(T&) and const lvalues would bind to g(T&) with T == 
const T.  And then g(T&) could easily distinguish between T and const T 
with is_const<T> (Metrowerks actually works this way, by accident, not 
by design).  However, the word on the street is that this sub-issue will 
be declared ambiguous.

-Howard