Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <4607@lupine.NCD.COM>
Date: 25 Mar 91 00:15:29 GMT
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 84

In article <1991Mar11.061204.6023@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes:
+In article <11152@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
+>I have heard a few references lately to the possibility of adding to c++
+>an overloadable operator dot. I have a few questions about this:
+>
+>1) Is the committee seriously considering this right now, or is this just
+>   a suggestion? If they are considering it, what are the chances of it
+>   passing?

It is being considered seriously by x3j16.

+>2) If this suggestion is actually used, what is the syntax to invoke
+>   the normal (un-overloaded) dot operator?
+>
+I guess one could always recover the original meaning by writing 
+(&x)->m or this->m. Note that the -> applies to a pointer and hence
+cannot be redefined.

In order to understand how this would work, I think that you would have
to look at the whole proposal.  I'm not sure, but I think that the idea
is to allow something like:

	expression.expression

If that is true, then this would be a lot different from the normal way
that thinsg work with ".".  In particular, you normally have to have
the name of a member (or the proper type) to the right of the dot.  The
thing to the right of the dot cannot be a general expression (as of now).
I believe that the "overloadable dot" proposal might change that, but
don't quote me.

+What are the reasons AGAINST allowing overloading operator.? 

I have said this over and over again, but either the "overloadable dot"
proposal is something radically different from what I think it is or
else some people are choosing to ignore some very basic facts.  (If it
is the latter...  well...  there would be nothing particularly new
about that!)

The bare fact of the matter (as I have said many times) is that "." is
plainly not an operator (either unary or binary).  It is a selector.

The C and C++ languages allow the thing on the left of the "." to
be an expression (of some struct/class type) but the thing on the
right is NOT an expression, rather it must be the name of a member
of the thing on the left.

In effect, dot acts a bit like the other "scope opener" that we know
about in C++, i.e. the colon-colon.  These things are plainly NOT
operators.  People who are just learning the language (as well as
experienced users) will just get more and more confused (when trying
to read code) if we start to bend the "normal" rules regarding what may
and may not be overloaded (or treated like an operator).

I have previously noted that allowing overloading for "." makes about as
much sense as allowing overloading for "{".  In both cases the very
idea appears ridiculous, however I actually read a response from one
person who said that (maybe) allowing overloading for "{" would be
a useful and good thing!!!

I guess the bottom line is this.  What is your opinion regarding how
a language should be designed?  Should it be an unbridled, nonsensical
and chaotic mismash of random "bright ideas" which seem like they might
occasionally have some obscure usefulness, or should there be some
rules, some guiding principals, and some *consistancy* in the set of
features provided by a language?

I feel that the design of C++ ought to have followed the simple (and
consistant) rule that overloading would only be allowed for things which
really are "operators".  Some people don't like to be bound by such
trivial concerns as "consistancy" however.  Some folks prefer the
"everything *including* the kitchen sink" approach to language design.
For those people, I have but one question.  Why stop with overloading "."?
Why not allow overloading for "{" and "}"?  What about overloading ":"
and/or "::"?  Come to think of it... why stop at just the tokens formed
from "special characters"?  Why not allow overloading of keywords?

If you are going to have an unconstrained free-for-all, why not go all
the way?
-- 

// Ron ("Shoot From The Hip") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.