From: 1czajnik@googlemail.com   
      
   { text reformatted to fit ~70 characters per line. -mod }   
      
   On Thursday, February 27, 2014 3:09:09 PM UTC+1, Daniel Krügler wrote:   
   [...]   
   > You are mixing two different concepts here: One concept is the core   
   > language concept of special member functions and these do specify that   
   > this class has a copy-assignment operator. Having a copy-assignment that   
   > also requires the existence of a move- or copy-constructor is not very   
   > useful, though. But this is not very special for move operations. You   
   > could alternatively declare the destructor as deleted without   
   > introducing any deleted copy/move constructor and the type still would   
   > not be able to copy-assign or even construct in a normal variable   
   > definition.   
   >   
   > The other concept is a an expression-based concept from the Standard   
   > Library: Copy/MoveConstructible and Copy/MoveAssignable. Both concepts   
   > are based on valid expressions, but they do not directly depend on the   
   > existence of the core language special member functions. For example a   
   > type without any special move member can still satisfy the   
   > MoveConstructible or MoveAssignable concepts, if it has accessible and   
   > non-deleted special copy member functions.   
   >   
   > Trying to deduce from the existence (or absence) of special members (the   
   > core language concept) the expression behaviour (the library concept),   
   > is a false analogy and can lead to surprises. E.g. the following type   
   > does have a deleted default constructor, but still can be   
   > aggregate-initialized:   
   >   
   > struct S {   
   >    S() = delete;   
   > };   
   >   
   > S s1; // Error   
   > S s2{}; // OK, aggregate initialization   
   >   
      
   Daniel, thank you for explaining this so patiently, it is very enlightening   
   for me. I was mixing the two concepts, and that was the root of my concerns.   
      
   [...]   
      
   > > I wonder, what should the traits is_copy_assignable and   
   is_move_assignable   
   > > report for the above four classes?   
   >   
   > These traits are referring to initialization forms and are not bound to   
   > the existence or absence of special members. That was not always the   
   > case. In fact the corresponding TR1 traits like has_trivial_copy,   
   > has_trivial_assign, or has_nothrow_copy were in fact inspecting the   
   > properties of special member functions. In this regard, the new   
   > is_copy/move_* traits are testing "expression" semantics and are more   
   > similar to the Library requirement sets (but do not impose behavioral   
   > requirements) and are often considered as more useful. Still, we have   
   > traits that solely inspect properties of core-language concepts, such as   
   > is_trivial or is_trivially_copyable. For example, the following type is   
   > trivially copyable, albeit it is not default-constructible,   
   > copy/move-constructible, copy/move assignable nor destructible:   
   >   
   > struct TC {   
   >    TC() = delete;   
   >    TC(const TC&) = delete;   
   >    TC(TC&&) = delete;   
   >    TC& operator=(TC&&) = delete;   
   >    TC& operator=(const TC&) = delete;   
   >    ~TC() = delete;   
   > };   
   >   
   [...]   
   > > I think it should be clearly stated, that   
   > > any class that has T& operator=( T ) has:   
   > > - a copy assignment operator iff it is copy constructable, and   
   > > - a move assignment operator iff it is move constructable.   
   > > (iff == if and only if)   
   >   
   > I have understood that your are comparing the core language definitions   
   > of the special member functions with a different concept set. This was   
   > the reason why I said in my previous response starting with "But I   
   > understand the point that you are trying to make". Please keep in mind   
   > that both concepts domains are different, albeit the core language   
   > concept has impact on the outcome of the library concept.   
   >   
   > HTH & Greetings from Bremen,   
   > Daniel Krügler   
      
   I think this became clear to me now. I will now try to verify my   
   understanding with some statements about this example:   
      
   struct B // movable only   
   {   
     B() = default;   
     B( B const& ) = delete;   
     B( B&& ) = default;   
     B& operator=( B ) {}   
   };   
      
   - B has a copy assignment operator.   
   - B has no move assignment operator.   
   - B is not copy assignable.   
   - B is move assignable.   
   - B is trivially copyable.   
      
   Did I get this right?   
      
   Thanks again for the explanation.   
      
   Regards,   
   Kris   
      
      
   --   
         [ 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)