From: marc.glisse@gmail.com   
      
   Daniel Krügler  wrote:   
      
   > unless you would be willing to standardize a type that *declares* a   
   > copy-constructor/assignment operator (and similar for the move   
   > operations), but might simply throw an exception "sorry, guys, my   
   > internals just tell me that I cannot copy". This will break all static   
   > deduction tools like std::is_copy_constructible (which say "yes, we   
   > can"), until the runtime tells us something different. I don't think   
   > that this would be a good idea.   
      
   I thought those static deduction tools were fairly unreliable to begin   
   with. I just checked on this simple example that a pair of move-only   
   types is reported as copy-assignable by g++, which blindly follows   
   the standard definition of std::pair. Actually assigning will result   
   in a compile-time error and not a runtime one though.   
      
   #include    
   #include    
   #include    
   #include    
   struct A {   
          A(){}   
          A(A const&)=delete;   
          A(A &&){}   
   };   
   int main(){   
          std::cout << std::boolalpha;   
          std::cout << std::is_copy_assignable >::value << '\n';   
          std::pair a,b;   
          // b=a;   
   }   
      
      
   --   
         [ 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)