title: Expected Moves vs Copies
body: <p>It is my understanding that move semantics can use move-constructors to elide what would otherwise be a copy.  For example, a function returning a (perhaps) large data structure can now return by value, and the move constructor will be used to avoid a copy.</p>
  
  <p>My question is this: is the compiler <em>required</em> to not copy when this is possible?  It doesn't seem to be the case.  In that case, wouldn't the following code have "implementation-defined" semantics?</p>
  
  <pre><code>static const int INVALID_HANDLE = 0xFFFFFFFF;
  
  class HandleHolder {
      int m_handle;
  public:
      explicit HandleHolder(int handle) : m_handle(handle) {}
      HandleHolder(HandleHolder&amp; hh) {
          m_handle = hh.m_handle;
      }
      HandleHolder(HandleHolder&amp;&amp; hh) : m_handle(INVALID_HANDLE) {
          swap(m_handle, hh.m_handle);
      }
      ~HandleHolder() noexcept {
          if (m_handle != INVALID_HANDLE) {
              destroy_the_handle_object(m_handle);
          }
      }
  };
  </code></pre>
  
  <p>Say then we make a function:</p>
  
  <pre><code>HandleHolder make_hh(int handle) { return HandleHolder(handle); }
  </code></pre>
  
  <p>Which constructor is called?  I would expect the move constructor, but am I <em>guaranteed</em> the move constructor?</p>
  
  <p>I'm aware this is a silly example and that -- for example -- the copy constructor of this object should be deleted because there is no way to use it safely otherwise, but the semantics are simple enough that I wouldn't think something like this would be implementation-defined.</p>