title: Should a move constructor take a const or non-const rvalue reference?
body: <p>In several places I've seen the recommended signatures of copy and move constructors given as:</p>
  
  <pre><code>struct T
  {
      T();
      T(const T&amp; other);
      T(T&amp;&amp; other);
  };
  </code></pre>
  
  <p>Where the copy constructor takes a const reference, and the move constructor takes a non-const rvalue reference.</p>
  
  <p>As far as I can see though, this prevents me taking advantage of move semantics when returning const objects from a function, such as in the case below:</p>
  
  <pre><code>T generate_t()
  {
      const T t;
      return t;
  }
  </code></pre>
  
  <p>Testing this with VC11 Beta, <code>T</code>'s copy constructor is called, and not the move constructor. Even using <code>return std::move(t);</code> the copy constructor is still called.</p>
  
  <p>I can see how this makes sense, since <code>t</code> is const so shouldn't bind to <code>T&amp;&amp;</code>. Using <code>const T&amp;&amp;</code> in the move constructor signature works fine, and makes sense, but then you have the problem that because <code>other</code> is const, you can't null its members out if they need to be nulled out - it'll only work when all members are scalars or have move constructors with the right signature.</p>
  
  <p>It looks like the only way to make sure the move constructor is called in the general case to have made <code>t</code> non-const in the first place, but I don't like doing that - consting things is good form and I wouldn't expect the client of <code>T</code> to know that they had to go against that form in order to increase performance.</p>
  
  <p>So, I guess my question is twofold; first, should a move constructor take a const or non-const rvalue reference? And second: am I right in this line of reasoning? That I should stop returning things that are const?</p>