From: dave@boostpro.com   
      
   on Wed Apr 04 2012, Kaba  wrote:   
      
   > This same post also addresses the replies of Daniel KrÌgler, SG, and   
   > Martin B., to avoid repeating things.   
   >   
   > Dave Abrahams wrote:   
   >> You're complaining that an lvalue ("that") passed through std::move   
   >> will bind silently to an rvalue reference, but I don't understand why   
   >> that's a problem for you.   
   >   
   > Well, that was not the problem. The 'problem' is that Type&& binds to a   
   > reference.   
      
   I don't mean to be blunt, but no.  Type&& is a reference.  References   
   only bind to objects, and references are not objects.  I think you mean   
   that it binds to an lvalue.   
      
   > The non-template function disallows it, while an innocent- looking   
   > generalization (by a template function) to an arbitrary type allows   
   > it.   
      
   Yes.   
      
   >   
   >> After all, std::move(x) *means*: "I grant   
   >> explicit permission to move from x, even if it's an lvalue."  If you   
   >> want to move only when the argument to f is an rvalue, then you write:   
   >>   
   >>       A b(std::forward(that));   
   >>   
   >> Seeing "Type&& that" in the declaration of f makes it look a bit like   
   >> "that" is bound to an rvalue, but it isn't (necessarily) so you can't   
   >> blithely use move() on it.   
   >   
   > Yes, this is clear, and this should be done after you are in the   
   > template function definition. My post referred to whether the template   
   > function should be callable at all with an lvalue (C++11 states that it   
   > is).   
      
   As it must be, or perfect forwarding wouldn't work.   
      
   > This reminds me a bit of the situation where the conversion operators   
   > are implicit by default, while a better choice would have been to have   
   > them explicit by default. Here the reference collapse rule   
   > A& && --> A& works by default, and can be disabled explicitly as Daniel   
   > KrÌgler shows. But perhaps a better choice would have been to have that   
   > rule disabled by default, and enabled explicitly by some notation (as   
   > Daniel KrÌgler and SG suggest).   
      
   Perhaps so.   
      
   > Watching the Going Native 2012 videos, I was positively impressed by the   
   > quality of the Clang error messages. Perhaps such heuristics will save   
   > us from making the mistake of moving instead of forwarding in this case.   
      
   Clang does a great job, no doubt.   
      
   --   
   Dave Abrahams   
   BoostPro Computing   
   http://www.boostpro.com   
      
      
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)