title: "Reference qualifier correctness" or should a non-const method ever apply to rvalues?
body: <p>Now that GCC 4.8.1 and Clang 2.9 and higher support them, reference qualifiers (also known as <a href="https://stackoverflow.com/q/8610571/2361316">"rvalue references for *this"</a>) have become more widely available. They allow classes to behave even more like built-in types by, e.g., disallowing assignment to rvalues (which can otherwise cause an unwanted cast of an rvalue to an lvalue):</p>
  
  <pre><code>class A
  {
      // ...
  
  public:
      A&amp; operator=(A const&amp; o) &amp;
      {
          // ...
          return *this;
      }
  };
  </code></pre>
  
  <p>In general, it is sensible to call a <code>const</code> member function of an rvalue, so an lvalue reference qualifier would be out of place (unless the rvalue qualifier can be used for an optimization such as moving a member out of a class instead of returning a copy).</p>
  
  <p>On the flip side, mutating operators such as the pre decrement/increment operators should be lvalue-qualified, as they usually return an lvalue-reference to the object. Hence also the question: Are there any reasons to ever allow mutating/non-<code>const</code> methods (including operators) to be called on rvalue references aside from conceptually <code>const</code> methods which are only not marked <code>const</code> because const-correctness (including proper application of <code>mutable</code> when using an internal cache, <a href="http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank" rel="nofollow noreferrer">which may include ensuring certain thread-saftey guarantees now</a>) was neglected in the code base?</p>
  
  <p>To clarify, I am not suggesting to forbid mutating methods on rvalues on the language level (at the very least this could break legacy code) but I believe that defaulting (as an idiom / coding style) to only allowing lvalues for mutating methods will generally lead to cleaner, safer APIs. However I am interested in examples where not doing so leads to cleaner, <a href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment" rel="nofollow noreferrer">less astonishing</a> APIs.</p>