Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <1991Mar25.154128.4138@world.std.com>
Date: 25 Mar 91 15:41:28 GMT
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu> <4607@lupine.NCD.COM>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 53

rfg@NCD.COM (Ron Guilmette) writes:
> 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.

Good advice.  The proposal that is most actively under discussion has the
same restriction on what follows overloaded "." as the current language
places on what follows overloaded "->", i.e., it has to be a member of
whatever class the left-hand side eventually resolves to.  (Like
operator->() might return an object with operator->() defined, operator.()
might return an object with operator.() defined; following the chain of
results must eventually produce something to which the built-in "->" or "."
can be applied.)

> 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 counter argument is that, if you can create a user-defined type that
acts like a pointer, which you can -- even without operator->(), if you're
willing to live only with the unary * notation -- why shouldn't you be able
to create a user-defined type that acts like a reference?  And if you do,
why should the syntax differ from that used with built-in references?  And
if the syntax is the same, what should you write as an operator in your
smart reference class to be invoked when you say "foo.bar"?

I agree that "." is _not_ an operator as I think of operators.  I just don't
have a better suggestion for how to write a smart reference class.

(In case anyone is confused by my postings on the subject, which appear to
blow both hot and cold on the idea of smart references, I have no
insuperable objections to the feature but have not yet been convinced that
there is enough of a need to override the minor concerns I have and my
desire not to fiddle with the language to add every "bright idea" that comes
along.)

>                                               should there be some
> rules, some guiding principals,

There have always been "guiding principals" (Bjarne and crew originally, now
X3J16); I think there have generally been guiding _principles_ as well.
(Sorry for the "principal/principle" pun, but I couldn't resist. :-)

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com