Why is a non-const rvalue move constructor called in this case?

Question

I have seen the related questions and they mostly talk about if we should have const rvalue references as a parameter or not. But I still fail to reason why a non-const move constructor is being called in the following code:

    #include <iostream>
    using namespace std;

    class A 
    {
    public:
      A (int const &&i) { cout << "const rvalue constructor"; }
      A (int &&i) { cout << "non const rvalue constructor"; }
   };


   int const foo (void)
   {
     const int i = 3;
     return i;
   }

  int main (void)
  {
     A a(foo());
  }

Godfather

Unrelated to your question, but returning a const value from a function is really quite meaningless. Nothing will stop the caller from storing the value in a non-const variable anyway. – Ark

@Someprogrammerdude, how can you get const rvalues then? – Godfather

Just for kicks, try your sample with a non-scalar type. ttbomk a const prvalue for a scalar is fictitious. – Hexa

@Godfather Const "values" of what type? What do you mean? What is the use case? – Sedberry

@curiousguy, yes for aggregates it calls the const T&& version. Why the variance? is it not something covered by standard? – Godfather

@Godfather There is no such thing as a const int rvalue. – Sedberry

Answer 1

Here is a slightly modified version of your code:

#include <iostream>

#if 0
using T = int;
#else
struct T {T(int){}};
#endif

    using namespace std;
    class A {
      public:
      A (T const &&i) { cout << "const rvalue constructor"; }
      A (T &&i) { cout << "non const rvalue constructor"; }
   };


   T const
   foo (void)
   {
     const T i = 3;
     return i;
   }

  int main()
  {
    A a(foo());
  }

When T == int, you get the non-const overload. When T is a class type, you get the const overload. This behavior falls out of section 8.2.2 [expr.type]/p2:

If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis.

Translation: The language doesn't have const-qualified scalar prvalues. They simply don't exist.

Selffertilization

Ah!! I thought one of the design goals of C++ was to make user-defined types behave as built-in types do. – Godfather

Design goals are often conflicting. Another design goal of C++ was to be compatible with C. – Selffertilization

@Godfather Being silly isn't a design goal. A scalar can just be copied. Moving from int is just pointless! – Sedberry

Oooh What an interesting tidbit! – Vandusen

@curiousguy, remembering different rules for scalar and aggregates is even more silly. – Godfather

@Godfather Copying a scalar is cheap; cheaper than stealing its value. So it's reasonable that a move from a scalar is a normal copy and doesn't change the source. And BTW, builtin operators are not overloaded operators. 1 + 1. doesn't go through overloading resolution. Implicit conversions of scalars are unlike user defined conversions. Pointers conversions are unlike smart pointer conversion. Covariant return types work with pointers not classes. static_cast, dynamic_cast... cannot be overloaded on classes. Etc. – Sedberry