Keeping in mind C++0x isn't quite standard yet, this is subject to change. From the FCD (PDF link), move constructors and move assignment operators can indeed be explicitly defaulted, and even implicitly defaulted.*
I'm just going to quote (heavily abridged) a bunch of stuff that might be useful to glance at:
On explicitly-defaulted functions, §8.4.2/1-2:
A function that is explicitly defaulted shall
- be a special member function,
- have the same declared function type as if it had been implicitly declared,
- not have default arguments, and
- not have an exception-specification.
If it is explicitly defaulted on its first declaration,
- it shall be public,
- it shall not be explicit,
- it shall not be virtual,
- it is implicitly considered to have the same exception-specification as if it had been implicitly declared (15.4), and
- in the case of a copy constructor, move constructor, copy assignment operator, or move assignment operator, it shall have the same parameter type as if it had been implicitly declared.
On special member functions, §12/1:
The default constructor (12.1), copy constructor and copy assignment operator (12.8), move constructor and move assignment operator (12.8), and destructor (12.4) are special member functions. [ Note: The implementation will implicitly declare these member functions for some class types when the program does not explicitly declare them. The implementation will implicitly define them if they are used. See 12.1, 12.4
and 12.8. —end note ]
About implicitly declared functions, §12.8/8-11:
If the class definition does not explicitly declare a copy constructor and there is no user-declared move constructor, a copy constructor is implicitly declared as defaulted (8.4).
The implicitly-declared copy constructor for a class X will have the form X::X(const X&)
if
- each direct or virtual base class B of X has a copy constructor whose first parameter is of type
const B&
or const volatile B&
, and
- for all the non-static data members of X that are of a class type M (or array thereof), each such class type has a copy constructor whose first parameter is of type
const M&
or const volatile M&
.
Otherwise, the implicitly-declared copy constructor will have the form X::X(X&)
.
If the class definition does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if
- X does not have a user-declared copy constructor and
- the move constructor would not be implicitly defined as deleted.
[ Note: When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise would have invoked the move constructor may instead invoke a copy constructor. —end note ]
The implicitly-declared move constructor for class X will have the form X::X(X&&)
.
On implicitly deleted default functions, §12.8/12:
An implicitly-declared copy/move constructor is an inline public member of its class. A defaulted copy-/move constructor for a class X is defined as deleted (8.4.3) if X has:
- a variant member with a non-trivial corresponding constructor and X is a union-like class,
- a non-static data member of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3), as applied to M’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, or
- a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3), as applied to B’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, or
- for the move constructor, a non-static data member or direct or virtual base class with a type that does not have a move constructor and is not trivially copyable.
§12.8/13-18 defines how the functions should work when they are implicitly generated.
§12.8/19 then does the same thing as §12.8/8 did, except with the copy-assignment and move-assignment operators. They are similar enough not to warrant quoting here.
For a more complete picture, you'll want to read those sections in their entirety, but that's the general idea. I'm glad we get implicit move semantics.
*But like defaulted copy-functions, they might not always have the correct behavior! The Big Three should become The Big Five. (For example, The Big Three are implemented whenever we need to deep-copy something. We also need to make sure we do a "deep-move", where the source's data is nulled/reset. This is not done implicitly.)