Why can overloaded operators not be defined as static members of a class?

I have no specific knowledge of any C++ discussion of this concept, so feel free to ignore this.

But to me, you've got the question backwards. The question should be, "why would this syntax be allowed?"

It provides no advantages at all over the current syntax. The non-static member function version has the same access to private members as your proposed static version. So if you need to access the privates to implement it, just make it a non-static member, exactly as you generally do with most members of a class.

It doesn't make it easier to implement asymmetric operators (ie: operator+(const X &x, const Y &y)). If you need private access to implement this, you'd still need a friend declaration for them in one of the classes.

So I would say that the reason it doesn't exist is that it isn't necessary. Between non-member functions and non-static members, all of the necessary use cases are covered.

Or, to put it another way:

Free functions can do everything that the static function system can, and more.

Through the use of free functions, you can get argument-dependent lookup happening for operators used in templates. You can't do that with static functions, because those would have to be a member of a particular class. And you cannot add to a class from outside of the class, while you can add to a namespace. So if you need to put an operator in a particular namespace in order to make some ADL code work, you can. You can't do that with static function operators.

Thus, free functions are a superset of everything that your proposed static function system would provide. Since there is no benefit to allowing it, there is no reason to allow it, and therefore it is not allowed.

which would make possible to use functors without instantiating them?

That is a contradiction in terms. A "functor" is a "function object". A type is not an object; therefore, it cannot be a functor. It can be a type that, when instantiated, will result in a functor. But the type alone will not be a functor.

Furthermore, being able to declare Typename::operator() static would not mean that Typename() would do what you want. That syntax already has an actual meaning: instantiate a Typename temporary by calling the default constructor.

Lastly, even if all that weren't the case, what good would that actually be? Most template functions that take a callable of some type work just as well with a function pointer as with a functor. Why would you want to restrict your interface, not merely to just functors, but to functors which cannot have internal data? That means you wouldn't be able to pass capturing lambdas and so forth.

What good is a functor that cannot possibly contain state? Why do you want to force the user into passing "functors" that don't have state? And why do you want to prevent the user from being able to use lambdas?

So your question is derived from a false assumption: even if we had it, it wouldn't give you what you want.

Because there isn't an obvious syntax to call such an operator, which would mean we'd have to make up something. Consider the following variables:

X x1;
X x2;

Now, let's pretend for a moment that we're using normal member functions instead of operators - let's say I changed operator+ to plus in your example.

Each of the three calls would look like:

x1.plus(x2);
plus(x1, x2);
X::plus(x1, x2);

Now when making an operator call using + how would the compiler know to look up your operator in the scope of X? It can't do it for normal static member functions, and operators aren't given special dispensation to disambiguate.

Now consider if you had both the second and third forms declared in your program. If you said x1 + x2 the compiler would either have to always pick the free function or the call would be ambiguous. The only real alternative would be something like x1 X::+ x2 which just looks ugly. Given all that, I'm sure the standards committee decided to simply forbid the static member version since anything it could accomplish could be done with a friend free function instead.

Static member functions can be used to utilities which help a class but for one reason or another are not members. It's easy to envision that among the utilities expressed as static class member functions, it might be useful to have operators.

Of course, if some overloaded operator takes a class C as its primary argument, there is no good reason to want that to be a static member of class C. It can just be a non-static member, so it obtains that argument implicitly.

However, a static member of class C might be an operator overloaded on some class other than C.

Say that there exists a file scope operator ==(const widget &, const widget &);. In my squiggle class, I am working with widget objects, but want a different comparison for them.

I should be able to make a static squiggle::operator == (const widget &, const widget &); for myself.

From the class scope, this is easy to call:

void squiggle::memb(widget a, widget b)
{
   if (a == b) { ... } // calls static == operator for widgets
}

from outside the class scope we can only call it using the explicit scope resolution combined with explicit operator call syntax:

void nonmemb(widget a, widget b)
{
   a == b;  // calls the widget member function or perhaps nonstatic operator
   squiggle::operator ==(a, b); // calls squiggle class' utility
}

This is not a bad idea. Furthermore, we can do it with regular overloaded functions, just not with operators. If comparison of widgets is done with a compare function, then there can be a non-member compare or a widget::compare and there can be a squiggle::compare that takes widgets.

So the only aspect of this which is not supported in C++ is the syntactic sugaring with operators.

Perhaps it's not a sufficiently useful idea to warrant support (so far!) After all, this isn't something which would allow some revolutionary reorganization of a C++ program. But it would fix an incompleteness in the language.

Also, consider that class overloads of operators new and delete are implicitly static! So the incompleteness already has a little exception.

hmmm... I am thinking about a static operator() which would implicitely delete all constructors... That would give us kind of typed functions. Sometimes I wish we had it in C++.