From: daniel.kruegler@googlemail.com   
      
   Am 24.02.2014 15:23, schrieb Krzysztof Czaiński:   
   > On Monday, February 17, 2014 9:35:29 PM UTC+1, Daniel Krügler wrote:   
   >> Krzysztof Czainski:   
   >>> So the standard treats A's assignment operator taking A by value as   
   >>> copy-assignment.   
   >>   
   >> Yes, this needs to be the case, because a operator= overload of the form   
   >>   
   >> T& T::operator=(T)   
   >>   
   >> was already a copy-assignment operator in previous versions of C++.   
   >>   
   >>> I think that's a shame. It works equally well as copy-assignment,   
   >>> move-assignment or any other assignment from a type convertible to   
   >>> A. That's the point of taking by value here.   
   >>   
   >> Could you explain what the particular problem is caused by this? If   
   >> you declare such an operator=, if will anyway be selected according to   
   >> overload resolution rules, so what harm does it do to A, if there is   
   >> no additional move-assignment operator?   
   >>   
   >> Or are your concerns related to the effects on B given the C++11 rules   
   >> modulo the applied fix by CWG 1402?   
   >   
   > Well the applied fix by CWG 1402 does fix my problem. (I'm not sure   
   > what you mean by 'modulo the applied fix by CWG 1402' ;-)   
      
   I was not sure whether you complained about the state even after   
   applying CWG 1402 to C++11 or whether your complaints were still about   
   the pre-fix wording.   
      
   > It's just that when I write:   
   >   
   > T& T::operator=(T)   
   >   
   > I intend it to be a universal assignment operator. Typically:   
   >   
   > T() = default;   
   > T( T const& ) = default;   
   > T( T&& ) = default;   
   >   
   > T& T::operator=( T x ) { swap(*this,x); return *this; }   
   >   
   > Here, I see T& T::operator=( T ) as a replacement for:   
   > T& T::operator=( T const& )   
   > T& T::operator=( T&& )   
   >   
   > Notice, that the following sets of overloads are ambiguous:   
   >   
   > T& T::operator=( T )   
   > T& T::operator=( T&& )   
   >   
   > or   
   >   
   > T& T::operator=( T const& )   
   > T& T::operator=( T )   
   >   
   > Therefore I believe   
   > T& T::operator=( T )   
   > is both the copy and move assignment operator.   
      
   Sure, it is possible to consider it conceptually this way, but   
   technically it is a copy assignment operator (as it had been in C++03)   
   and this difference becomes obvious, if you consider the effects on   
   "container" types - that is types, that either contain T as non-static   
   data member or as a direct base class: Because T& T::operator=(T)   
   declares a copy-assignment operator, the corresponding "container" type   
   will (implicitly) always declare a copy-assignment operator as well.   
      
   > But like I mentioned above, the applied fix by CWG 1402 does fix my   
   > problem, and I don't see any other problematic examples this could cause.   
   >   
   > But then, calling:   
   > T& T::operator=( T )   
   > "copy assignment" is misleading to me, because it seems no more a copy   
   > assignment than a move assignment.   
      
   I would argue that describing this function as copy assignment character   
   of T makes sense, because you can apply an lvalue of T as argument, but   
   for any move-assignment operator this would not be possible. And if the   
   argument is an lvalue, this function will never modify it, so it truly   
   is non-mutating for lvalues. But I understand the point that you are   
   trying to make: For non-constant rvalues this function behaves   
   potentially mutating and has therefore some aspects of a typical move   
   operation.   
      
   HTH & Greetings from Bremen,   
      
   - Daniel Krügler   
      
      
      
   --   
         [ 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)