TITLE: Why operator [] must be a member function


PROBLEM: b91926@fsgm01.fnal.gov (David Sachs)

One thing I find to be incomprehensible is that operator[] is
required to be a member function. Among other things this actually
destroys some similarity to the built-in [] operator, which among other
things is commutative (blech).

While I can see good reasons for this requirement for operator=,
operator() and operator->, [] is really a normal binary operator.
I can see good use for overriding subscripting with a class object
as the second operand.


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 25 Apr 95

I believe the reason for requiring operator[] to be a class member function
was to prevent type conversion on the left operand. For a somewhat silly
example, suppose you had
	class T { ... T(int); ... };
	typedef ... U;
	U& operator[](const T&, int);

	int t;
	T t1;
	U u = t[3]; // oops, meant t1[3]

What would happen? A temp object of type T would be constructed, initialized
with the value t, and that object would be indexed by 3. If operator[] were
a member function, you would get an error message at compile time instead.

More generally, you would also have more opportunities for ambiguity.
For example, there might be different classes around which could be
constructed from the type on the left of the "[]", and for which an
operator[] was available. Instead of trying to cope with this mess,
the rule was adopted that elminated the possibility of this particular
mess. Remember, the rule came years before the "explicit" keyword was
proposed.