In article <57570@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>-- Please join me in lobbying the ANSI C++ committee to correct this oversight
>in the language definition.  Overloading operator.() makes equal sense for
>reference classes as overloading operator->() for pointer classes...

Finally, Jim and I have found something to agree on. :-)

I'd say that Jim is correct is saying that treating either `.' or `->' as
if they were OPERATORS (kinda like other operators) makes equal sense,
i.e. *NONE*!  Allowing overloading for either of these makes about as
much sense as allowing overloading for `{' or `}'.

Look folks, just because a particular C++ token contains some non-
alphanumeric characters does not make it an operator!

OK.  Back to basics.  What is `->'?

Well, it is (syntactic sugar) shorthand notation for `*.' (i.e.
dereference and select).  So whenever I write:

 a->b

(in C anyway) that's always equivalent to:

 (*a).b

The meaning is clear and unambiguous.  Apply the prefix unary dereference
operator to the thing on the left, and then select out a member from the
result.

Now I've got no problem with (or objection to) allowing overloading for
the unary prefix dereference operator BECAUSE THAT *IS* AN OPERATOR IN
EVERY SENSE OF THE WORD.

I do object (most violently) however to any attempts to call the selector
`.' a `binary operator' (or to treat it as though it were one).  Obviously,
it isn't.

For all of the binary operators that *I* know of, either the left or the
right operands may be arbitrarily complex *expressions* (so long as these
expressions evaluate to some type of value which is appropriate for the
given category of operator).

This is clearly *not* true in the case of the selector `.'.  For the
selector, the thing on the right *must* be a (qualified or unqualified)
identifier which designates a some member belonging to the type of the
thing on the left.  The thing on the right *cannot* be an arbitrarily
complex expression.  It must be an identifier.  Furthermore, the identifier
*cannot* refer to any complete *object*.  Rather, it must refer to a
*member*.

So the selector is *not* an operator.  Period.  Allowing overloading for
it would make about as much sense as allowing overloading for `{' or `}'
or `::' or `"'.

Likewise, since `->' is just a shorthand notation for a combination of
an operator (i.e. unary prefix dereference) and the selector, allowing
overloading for `->' make as little sense as allowing it for the selector
all by itself, i.e.  none whatsoever.

I can't understand why Bjarne and Jim and others have so much difficulty
seeing the fundamental irrationality of allowing operator overloading
to be done to things which are clearly not operators.

If they really think that this is such a swell idea, then I challenge them
to tell me (and everyone) why they are not suggesting allowing `operator{'
to be overloaded.

If there are any rules for what should be called an operator and what should
not, and what should be overloadable and what should not, I'd like to see
them!  If these rules are at all consistant, if they make any sense
whatsoever, and if they still would seem to permit -> to be overloaded,
I'll eat my hat.
--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.