Bogus name lookup by overloaded operators

[Ewgenij Gawrilow]

>>>>> "Martin" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

    >> I've already started to doubt that these operators should be treated as
    >> lexically distinct, but then found a similar example in the Standard,
    >> par. 13.3.1.2.10. Thus I consider it's yet a bug.

    Martin> The example demonstrates that 'a+a' looks for A::operator+, so it
    Martin> is a qualified lookup. As a result, the shadowing of A::operator+
    Martin> by B::operator+ (which would normally happen) has no effect.

OK, indeed I've seen that the example cited in the Standard isn't exactly the
same. I've referred to it, however, in order to stress that the lookup rules
for operators are allowed to be different from those for normal functions (or
even operators called using functional notation).

When one names a function so that it collides with other already defined
functions, one does it deliberately, with a purpose to resolve the ambiguity
later somehow, e.g. with "using" statement. Or one does it in error, and having
been warned by the compiler, has to rename it. At any rate, one has freedom to
some extent in how to name one's functions.

But there is no freedom by the operators at all! When I redefine unary *, I
have dereferencing in mind, and for binary * - some flavor of algebraic
multipliplication. If I want that my classes are semantically interchangeable
with other STL or built-in types, I can't rename these operations!

Thus I think the lookup rules should be adjusted in such a way that unary
and binary operators that PURELY OCCASIONALLY but UNAVOIDABLY share the same
operation sign, are treated as different and mutually independent names.

With best regards,
Ewgenij Gawrilow
Dept. of Mathematics, Technical University of Berlin