Cheers, Sebastian

That said, this looks like another place where concepts reveal a flaw in the rvalue reference design. Something like

struct X
{
    template <SomeConcept T>
    X(T&&);
 
    template <SomeConcept T>
    X(T const&);
};

where it is known how to move from all models of SomeConcept, would be a problem. In C++ without concepts, you can have the same problem if you replace SomeConcept with a SFINAE constraint:

struct X
{
    template <class T>
    X(T&&, typename enable_if<some_constraint<T> >::type* = 0);
 
    template <class T>
    X(T const&, typename enable_if<some_constraint<T> >::type* = 0);
};

Still, as of today, no real use-case has cropped up that would cause the problem.

template< typename Type,
          class = typename std::enable_if
          <
              !std::is_lvalue_reference<Type>::value
          >::type>
void fun( Type && )     // #2
{
    std::cout << "move";
}

Now fun(n) outputs “copy”.

Alternatively you could put all of the logic under #2 since it will accept everything:

template< typename Type>
void fun( Type && )     // #2
{
    if (std::is_lvalue_reference<Type>::value)
        std::cout << "copy";
    else
        std::cout << "move";
}

// fun(n) -> copy

That “run time if” could also be a compile-time-if:

void fun_impl(std::true_type)
{
   std::cout << "copy";
}

void fun_impl(std::false_type)
{
   std::cout << "move";
}

template< typename Type>
void fun( Type && )     // #2
{
    fun_impl(std::is_lvalue_reference<Type>());
}

// fun(n) -> copy

There are lots of options, and the best one depends on what you want to do. In practice I’ve found that I don’t usually want to overload T&& and const T& for a truly generic T. Far more often T is partially specialized. E.g. I usually want to overload on vector<T>&& and const vector<T>&.

I should note that I did not make the alternative suggestion because of specific issues I foresaw: It was just an intuition that introducing a new kind of reference would have difficult-to-tract ramifications and make the feature less accessible to the C++-programming community. (Had I anticipated the issues you and others have discovered since then, maybe I’d been more forceful. )

True.

I just wanted to clarify that we (you, I , Howard, etc.) could think (and had thought) of other ways. There were from the start people (e.g., colleagues and I) who thought the merging of “moving” and “forwarding” was a terrible idea, and we sketched out “other ways” (where “from the start” means during informal discussions, before a formal rvalue reference proposal was made).

My bad for not putting in the energy to push those sketches forward as a competing proposal.

That’s perfectly true; I wrote imprecisely. There were lots of other ideas raised, but you know as well as I do that there’s worlds of difference between “voicing a preference” and presenting a viable proposal. At one point (the previous Santa Cruz meeting), the committee sent us back to the drawing board to work on trying to realize some of the competing ideas. IIRC Jason Merrill was the only one who showed up for the in-depth conversations and his ideas turned out not to work. In fact, history is littered with approaches people thought were “obviously better,” that turned out to be fatally flawed in some way. I guess after seeing a few of those, I probably wasn’t ready to invest time in proposals that weren’t fairly complete and solid.

Dave Abrahams: The short answer is, “because we couldn’t think of another way.”And if you want to know why your idea almost certainly wouldn’t be accepted, it’s just because it’s now too late in the standardization cycle.All I can say is, “where have you been for the past 10 years?”I would have welcomed ideas like this one.   

I don’t think that’s quite right: I (and others) voiced my preference for not trying to fit everything under the rvalue reference type, and instead introduce forwarding-specific notation. E.g.:

template void ff(for T) { … } // T deduced to & or &&

(I also suggested not introducing rvalue reference types at all, and handle rvalue-vs-lvalue overloading with another parameter modifier.)

Dave Abrahams: Of course it depends on #1 somehow being taken out-of-contention

Won’t #2 always be chosen for non-const lvalues? (gcc with the following code prints “move”)

  template< typename Type >
  void fun( Type const& ) // #1
  {
    std::cout << "copy";
  }
 
  template< typename Type >
  void fun( Type && )     // #2
  {
    std::cout << "move";
  }
 
  int main()
  {
    int n;
    fun(n);
  }