Why can't you overload the '.' operator in C++?

Stroustrup has an answer for this question:

Operator . (dot) could in principle be overloaded using the same technique as used for ->. However, doing so can lead to questions about whether an operation is meant for the object overloading . or an object referred to by . For example:

class Y {
public:
void f();
// ...
};
class X {   // assume that you can overload .
Y* p;
Y& operator.() { return *p; }
void f();
// ...
};
void g(X& x)
{
x.f();  // X::f or Y::f or error?
}

This problem can be solved in several ways. At the time of standardization, it was not obvious which way would be best. For more details, see D&E.

See this quote from Bjarne Stroustrup:

Operator . (dot) could in principle be overloaded using the same technique as used for ->. However, doing so can lead to questions about whether an operation is meant for the object overloading . or an object referred to by . For example:

class Y {
public:
void f();
// ...
};


class X {    // assume that you can overload .
Y* p;
Y& operator.() { return *p; }
void f();
// ...
};


void g(X& x)
{
x.f();    // X::f or Y::f or error?
}

This problem can be solved in several ways. At the time of standardization, it was not obvious which way would be best. For more details, see The Design and Evolution of C++.

Stroustrup said C++ should be an extensible, but not mutable language.

The dot (attribute access) operator was seen as too close to the core of the language to allow overloading.

See The Design and Evolution of C++, page 242, section 11.5.2 Smart References.

When I decided to allow overloading of operator ->, I naturally considered whether operator . could be similarly overloaded.

At the time, I considered the following arguments conclusive: If obj is a class object then obj.m has a meaning for every member m of that object's class. We try not to make the language mutable by redefining built-in operations (though that rule is violated for = out of dire need, and for unary &).

If we allowed overloading of . for a class X, we would be unable to access members of X by normal means; we would have to use a pointer and ->, but -> and & might also have been re-defined. I wanted an extensible language, not a mutable one.

These arguments are weighty, but not conclusive. In particular, in 1990 Jim Adcock proposed to allow overloading of operator . exactly the way operator -> is.

The "I" in this quote is Bjarne Stroustrup. You cannot be more authoritative than that.

If you want to really understand C++ (as in "why is it this way"), you should absolutely read this book.

It is very easy to understand, if you go through the internal mechanism of operator function invocation, Say a class complex can have two member r for real part and i for imaginary part. Say Complex C1(10,20),C2(10,2) // we assume there is an already a two argument constructor within class. Now if you write C1+C2 as a statement then compiler try to find the overloaded version of + operator on complex number. Now we assume that I overload + operator, so C1+C2 internally translated as c1.operator+(c2) Now assume for the time beings you can overload '.' operator. so now think following call C1.disp()//display content of a complex object Now try to represent as an internal representation C1.operator.(------) , completely messy things created. That is the reason why we can't overload '.' operator