Back to Item 14: Make sure base classes have virtual destructors.
Continue to Item 16: Assign to all data members in operator=.

Item 15: Have `operator=` return a reference to `*this`.

°Bjarne Stroustrup, the designer of C++, went to a lot of trouble to ensure that user-defined types would mimic the built-in types as closely as possible. That's why you can overload operators, write type conversion functions (see Item M5), take control of assignment and copy construction, etc. After so much effort on his part, the least you can do is keep the ball rolling.

Which brings us to assignment. With the built-in types, you can chain assignments together, like so:

    int w, x, y, z;

    w = x = y = z = 0;

As a result, you should be able to chain together assignments for user-defined types, too:

    string w, x, y, z;               // string is "user-defined"
                                     // by the standard C++
                                     // library (see Item 49)

    w = x = y = z = "Hello";

As fate would have it, the assignment operator is right-associative, so the assignment chain is parsed like this:

    w = (x = (y = (z = "Hello")));

It's worthwhile to write this in its completely equivalent functional form. Unless you're a closet LISP programmer, this example should make you grateful for the ability to define infix operators:

    w.operator=(x.operator=(y.operator=(z.operator=("Hello"))));

This form is illustrative because it emphasizes that the argument to `w.operator=`, `x.operator=`, and `y.operator=` is the return value of a previous call to `operator=`. As a result, the return type of `operator=` must be acceptable as an input to the function itself. For the default version of `operator=` in a class `C`, the signature of the function is as follows (see Item 45):

    C& C::operator=(const C&);

You'll almost always want to follow this convention of having `operator=` both take and return a reference to a class object, although at times you may overload `operator=` so that it takes different argument types. For example, the standard `string` type provides two different versions of the assignment operator:

    string&                            // assign a string
    operator=(const string& rhs);      // to a string

    string&                            // assign a char*
    operator=(const char *rhs);        // to a string

Notice, however, that even in the presence of overloading, the return type is a reference to an object of the class.

A common error amongst new C++ programmers is to have `operator=` return `void`, a decision that seems reasonable until you realize it prevents chains of assignment. So don't do it.

Another common error is to have `operator=` return a reference to a `const` object, like this:

    class Widget {
    public:
      ...                                            // note
      const Widget& operator=(const Widget& rhs);    // const
      ...                                            // return
    };                                               // type

The usual motivation is to prevent clients from doing silly things like this:

    Widget w1, w2, w3;

    ...

    (w1 = w2) = w3;         // assign w2 to w1, then w3 to
                            // the result! (Giving Widget's
                            // operator= a const return value
                            // prevents this from compiling.)

Silly this may be, but not so silly that it's prohibited for the built-in types:

    int i1, i2, i3;

    ...

    (i1 = i2) = i3;                // legal! assigns i2 to
                                   // i1, then i3 to i1!

I know of no practical use for this kind of thing, but if it's good enough for the `int`s, it's good enough for me and my classes. It should be good enough for you and yours, too. Why introduce gratuitous incompatibilities with the conventions followed by the built-in types?

Within an assignment operator bearing the default signature, there are two obvious candidates for the object to be returned: the object on the left hand side of the assignment (the one pointed to by `this`) and the object on the right-hand side (the one named in the parameter list). Which is correct?

Here are the possibilities for a `String` class (a class for which you'd definitely want to write an assignment operator, as explained in Item 11):

    String& String::operator=(const String& rhs)
    {

      ...

      return *this;            // return reference
                               // to left-hand object
    }

    String& String::operator=(const String& rhs)
    {

      ...

      return rhs;              // return reference to
                               // right-hand object
    }

This might strike you as a case of six of one versus a half a dozen of the other, but there are important differences.

First, the version returning `rhs` won't compile. That's because `rhs` is a reference-to-`const`-`String`, but `operator=` returns a reference-to-`String`. Compilers will give you no end of grief for trying to return a reference-to-non-`const` when the object itself is `const`. That seems easy enough to get around, however — just redeclare `operator=` like this:

    String& String::operator=(String& rhs)   { ... }

Alas, now the client code won't compile! Look again at the last part of the original chain of assignments:

    x = "Hello";                     // same as x.op=("Hello");

Because the right-hand argument of the assignment is not of the correct type — it's a `char` array, not a `String` — compilers would have to create a temporary `String` object (via the `String` constructor — see Item M19) to make the call succeed. That is, they'd have to generate code roughly equivalent to this:

    const String temp("Hello");      // create temporary

    x = temp;                        // pass temporary to op=

Compilers are willing to create such a temporary (unless the needed constructor is `explicit` — see Item 19), but note that the temporary object is `const`. This is important, because it prevents you from accidentally passing a temporary into a function that modifies its parameter. If that were allowed, programmers would be surprised to find that only the compiler-generated temporary was modified, not the argument they actually provided at the call site. (We know this for a fact, because early versions of C++ allowed these kinds of temporaries to be generated, passed, and modified, and the result was a lot of surprised programmers.)

Now we can see why the client code above won't compile if `String`'s `operator=` is declared to take a reference-to-non-`const` `String`: it's never legal to pass a `const` object to a function that fails to declare the corresponding parameter `const`. That's just simple `const`-correctness.

You thus find yourself in the happy circumstance of having no choice whatsoever: you'll always want to define your assignment operators in such a way that they return a reference to their left-hand argument, `*this`. If you do anything else, you prevent chains of assignments, you prevent implicit type conversions at call sites, or both.

Back to Item 14: Make sure base classes have virtual destructors.
Continue to Item 16: Assign to all data members in operator=.