Why do we use return *this in overloaded assignment?

Question

I am a student of computer science. Please read my question fully before answering

In C++ class today we learned about overloaded operators, in particular the assignment operator, and my professor said something he doesn't like to: "Just trust me." He uttered this line in reference to the return *this convention.

I asked, "But why?" and his answer was pretty much, "Because it is."

I am not satisfied with this answer.

Consider the following:

class length
{
private:
     int inches, feet, yards;
public:
    //getters, setters, etc.
    Length operator=(const Length& Q)
    {
        this->inches = Q.inches;
        this->feet = Q.feet;
        this->yards = Q.yards;
        return *this;
    }
};

I understand based on mucking about through countless questions and at least 3 C++ books that the "Convention" exists because it allows chained assignments but why is it necessary and how did it come to be?

A more in-depth question is how does this have individual "child pointers" (my term, not official) to the properties of the class (IE this->inches)? How does that work? Is this->inches just an offset or something?

My professor and I would REALLY appreciate an answer that isn't just "Because it's how it's done."

Please and Thank You

edit: I thought I was clear in writing the question; however, based on the responses I have been getting, I believe there has been a miscommunication. I am seeking to understand where the convention came from (roots in C I believe) and why it is this way.

Answer 1

The consensus seems to be that operator= traditionally returns *this to enable constructs such as:

a = b = c

which is the traditional behavior of C extended to classes.
By the way, the signature of your operator= should probably be:

Length& operator=(const Length& Q);

because you don't want to create a new temporary object sa return value

Answer 2

Since you are not satisfied with the answer "Because it is", let me give you a different one:

When overloading operators, do as int does

The reason for that recommendation is to follow the principle of least surprise, people are used to the operator looking and behaving in a particular way for the existing types. When they use the operator with your type, there is an implied expectation that it will behave the same.

Now the next question is why do int behave this way? For that I don't have a clear answer. It enables some fancy syntax like: (a = 3) = 5, ++(a = 3) or (x = y).change(), but it is unclear what the real value is in any of those three cases. In the first case, you can directly assign 5, in the other two cases rewriting the expression as two separate expressions would make the code more readable.

I intentionally avoided the case of a = b = c in the previous argument, as this case supports the idea that the operator should yield a value, or a reference so that it can be used in a later assignment, but the convention is to return a modifiable reference, and the expression above does not required this. A const & would suffice to support the above syntax. [And then again, is that syntax really needed? What is the cost of splitting that into two statements? Would it not be more readable? (in many cases it might be better, in some case it might not)].

At any rate the lesson to take home is to follow the principle of least surprise, and whatever the rationale that led to this behavior for all fundamental or otherwise standard types, once it becomes an idiom it is better to just follow it.

Answer 3

Assignment is an expression. It has both an effect (copying some data from its right-hand side to its left-hand side) and a value. Unless you want to break convention and make weird things happen, that value is the thing on the left hand side (i.e. this). That way if (a = b) is true if a became true from the assignment, and a = b = c assigns c to both a and b.

The reason it's best to return this by reference, and not by value, as stated in this answer, is that it avoids unnecessary copying.