title: Force a compile time error if std::move will result in an unintended copy?
body: <p>In his GoingNative 2013 talk, Scott Meyers pointed out that <code>std::move</code> is no guarantee that the generated code will actually perform a move.</p>
  
  <p>Example:</p>
  
  <pre><code>void foo(std::string x, const std::string y) {
    std::string x2 = std::move(x); // OK, will be moved
    std::string y2 = std::move(y); // compiles, but will be copied
  }
  </code></pre>
  
  <p>Here, the move constructor cannot be applied but because of overload resolution, the normal copy constructor will be used instead. This fallback option may be crucial for backward compatibility with C++98 code, but in the example above it is most likely not what the programmer intended.</p>
  
  <p><strong>Is there a way to enforce that a move constructor will be called?</strong></p>
  
  <p>For example, assume that you want to move a huge matrix. If your application really depend on the Matrix to be moved, it would be great to immediately get a compile error if a move is not possible. (Otherwise, you the performance problem may slip easily through unit tests and you will only find out after some profiling.)</p>
  
  <p>Lets call this guaranteed move <code>strict_move</code>. I would like to be able to write code like this:</p>
  
  <pre><code>void bar(Matrix x, const Matrix y) {
    Matrix x2 = strict_move(x); // OK
    Matrix y2 = strict_move(y); // compile error
  }
  </code></pre>
  
  <p>Is it possible?</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Thanks for the great answers! There were some legitimate requests to clarify my question:</p>
  
  <ul>
  <li>Should <code>strict_move</code> fail if the input is const?</li>
  <li>Should <code>strict_move</code> fail if the result will not lead to an actual move operation (even though the copy might be as fast as a move, e.g., <code>const complex&lt;double&gt;</code>)?</li>
  <li>Both?</li>
  </ul>
  
  <p>My original idea was very vague: I considered Scott Meyers examples quite alarming, so I wondered if it is possible to have the compiler prevent such unintended copies.</p>
  
  <p>Scott Meyers mentioned in his talk that a general compiler warning is not an option as it would result in a huge number a false positives. Instead I want to communicate to the compiler something like "I'm 100% sure that this must always resulting in a move operation and a copy is too expensive for this specific type".</p>
  
  <p>Thus, I would have offhandedly said that <code>strict_move</code> should fail in both cases. Meanwhile I'm not sure what would be best. Another aspects that I didn't consider is <code>noexcept</code>.</p>
  
  <p>From my side, the exact semantics of <code>strict_move</code> are open. Everything that helps to prevent some dumb mistakes at compile time without having serious drawbacks is fine.</p>