Re: C++0x: unfortunate interaction of rvalue references and concepts

Hi!

I noticed some unfortunate gotchas when using both features (rvalue
references and concepts/templates) which I'm going to mention here.
Most importantly: The current spec draft seems to contain such a bug
in the way std::vector (and possibly other containers as well) are
defined:

in 23.2.6 (page 826 of N2798.pdf) we have

   requires AllocatableElement<Alloc, T, const T&>
   void push_back(const T& x);

   requires AllocatableElement<Alloc, T, T &&>
   void push_back(T&& x);

The problem is: rvalue references are allowed to bind to lvalues.
Overloading is necessary in this case to distinguish between lvalues
and rvalues. But not all types might be copyable which is why the
first push_back function has an such an additional requirement.
Unfortunately it won't contribute to overload resolution for non-
copyable types. In case of non-copyconstructible types it's possible
to call push_back on lvalues that are possibly destroyed because only
push_back(T&&) is the only function in the overload resolution set.

Quick fix: Add this declaration:

   requires !AllocatableElement<Alloc, T, const T&>
   void push_back(const T& x) = delete;

so that a push_back function taking an lvalue reference is ALWAYS part
of the overload resolution set.

Here is another nother gotcha:

The template type parameter deduction rule for rvalue references that
is needed for perfect forwarding makes implementing move semantics
error-prone:

   template<typename T> void foo(T const& x); // #1
   template<typename T> void foo(T && x); // #2

In this case #2 is ALWAYS called for non-const objects since T might
be deduced to be an lvalue reference. To circumvent this we need to
apply SFINAE a la

   template<typename T>
   typename disable_if_reference<T,void>::type
   foo(T && x); // #2

There's a third case where this type parameter deduction may cause
problems: Conceptualized perfect forwarding doesn't seem to be easily
possible:

   concept C<typename T> {}
   concept_map C<int> {}

   template<C T>
   void do_something(T && x);

   int main() {
      int k = 42;
      do_something(23); // OK
      do_something(k); // fails since T=int& and !C<int&>
   }

So, we have to resort to code like this:

   template<typename T>
   requires C<typename remove_reference<T>::type>
   void do_something(T && x);