From: jimad@microsoft.com
Newsgroups: comp.lang.c++
Date: 17 Jul 92 23:42 MDT
Subject: Re: Committee Members -> What do you th
Nf-ID: #R:710560778snx@whizbang.wariat.org:639459369:1992Jul17.194202.14981@microsoft:-1529294247:001:8413
Nf-From: microsoft.com!jimad    Jul 17 23:42:00 1992


In article <1992Jul15.144839.18494@sco.COM> paul@sco.COM (Paul Jackson) writes:
|By George, I think he's got it! A standard is NOT meant to be a perfect
|definition of a language that will stand unchanged for eternity, it is meant
|to be a checkpoint of "current" practice that allows programmers who care to
|write maximally portable code (note that these two features often conflict
|which is why standards have implementation defined and undefined behaviour).
|I put current in quotation marks since it is expected (and thought to be a
|good thing) that by the time a standard actually finishes wending its way
|through the system the current state of the art will already have passed it
|by.

Your definition of what a "standard" "is" flies in the face of the reality
of the ANSI-C++ committees actions.  In some cases, for example exceptions,
they have ignored existing implementations and chosen to require something
new different and not implemented in any compilers.  In other cases, such
as templates, they have decided to standardize on something that compilers
had not only not yet implemented, but which have not to this day been
even half-specified.  Thus compiler-implementors rush to support templates,
knowing not what they are suppose to implement, with the result that
each compiler claims they have templates, but it is virtually impossible
to write a meaningful template class that will work on various compilers.
In other cases the committee is soliciting "standard" class library 
designs invented out of whole cloth -- classes for which there is no
implementation anywhere.  In other cases, such as name space, the committee
decided that existing implementations didn't have it right and they'd just
redesign the whole thing ....

.... So, I don't disagree with you're idea of what a "standard" SHOULD
be -- in which case ANSI-C++ should just have been "2.1"  BUT  given that
the ANSI-C++ effort IN NO WAY corresponds to your definition of what a 
"standard" should be, then you argument cannot stand as an argument against
"fixing" the current erroneous rationale for special case language 
prohibiting operator.().

|A large number of C vendors (I suspect almost all) provide a compiler which
|supports several dialects of the C language. One of these (usually not the
|default) is a strict Ansi C dialect, another is usually an "extended"
|version of the standard Ansi C dialect. The Ansi C dialect is maximally
|portable, the extended environment is generally "richer" and has more
|"features". In a few years, people will again get together and decide which
|set of features are sufficiently useful to be worth incorporating into the
|new standard for the language and a new standard will emerge.

In a few years the ANSI-C++ committee will be [at best] just wrapping up
the proposed ANSI-C++ standard.  The standard will then go through several
years of public review before ratification.  The standard will then require
several more years before compiler vendors really bring their compilers into
conformance.  This is nothing new -- simply review the history of ANSI-C and
you can see how the ANSI-C++ process will progress!  Again, you are describing a 
process VERY DIFFERENT from the actual actions of the ANSI-C++ committee, thus
your statement have no basis in reality as an argument against operator.()

|Getting back to operator dot, it may or may not make it into this (or any
|future) standard. If "almost everybody" implements it, or "almost everybody"
|demands it or "almost everybody" agrees that it is a good idea then it will
|"almost certainly" make it in. If not, the chances are lower.

On the contrary "almost everybody" will have no say in this matter, as
history has already shown.  On the contrary, a couple people on the 
extensions committee will either support the idea, or talk it down, and
that will be sufficient to get it on, or keep it off, the floor of the
committee whole for a vote.

|Personally, I feel that it is just not too important an issue one way or
|another. Its a fairly minor piece of syntactic sugar that has reasonably
|minor benefits and costs. Since my personal prejudices are against making
|extensions to the language I'm against adding operator . but I hardly feel
|that it is a "make or break" issue.

Operator.() is only necessary if one is interested in having complete
and safe "smart pointer", "smart reference", "smart array", "reference
counting" classes etc.  If you aren't interested in these things, if
you aren't interested in making "smart" classes by using templates, etc,
then you are not interested in operator.().  You probably aren't interested
in unary operator&(), unary operator->(), unary operator*() EITHER --
but THOSE things ARE in the language already.  So the idea that the language
should be left in error, and unorthogonal, just because you aren't interested
in any of these "smart" things is not an argument.

Personally, *I* couldn't care less if anyone bothers to fix some of the 
nuances of the name space problems in C++ -- because I'M NEVER going to
make use of those nuances.  Does it thereby follow that NO committee member
should "fix" the name space problems?

Further:

This issue has been discussed dozens of times before.  OPERATOR.() IS NOT
A LANGUAGE EXTENSION -- IT IS A LANGUAGE REDUCTION -- IT IS A REMOVAL OF
AN ERRONEOUS AND UNNECESSARY PIECE OF SPECIAL CASE LANGUAGE IN THE SPEC.

Please -- for the NTH time -- Please read ARM  page 330:

"The reason for disallowing the overloading of ., .*, and ::  is that
 they already have a predefined meaning for objects of any class as their
 first operand."

Followed by:

"The predefined meaning of the operators =, (unary) &, and , (comma)
 applied to class objects may be changed."

Again summarizing:

Operator.() can't be overloaded because it has predefined meaning.

Operator&() CAN be overloaded even though it has predefined meaning.

This is plain and simple a language design bug.  The rationale is
irrational.

Some committee members simply say "who cares, we the committee members 
do not have to act rational."

Which is a true statement, but it is not a rationale.  If the committee membes
insist on standardizing on bugs, there is nothing the rest of us can do
about the situation -- except point out the stupidity of such actions.

MY suggested solution to the bug is simply to remove the erroneous and 
unnecessary special case language in the spec.  In which case operator.()
works "just like" the other operators, in particular "just like" operator->().
This makes operator.() UNARY NOT BINARY.  Some people continue to fail to 
understand that a UNARY operator CANNOT depend on something that IS NOT one of 
its parameters, and that conversely that an operator that depends on TWO 
parameters IS a BINARY operator.  Thus if whether or not an overloaded operator.
is invoked in preference to a built-in operator. depends on the RHS of
the . , in addition to the LHS of the dot, then people MUST BE talking about
a BINARY operator.().  If one COULD write a BINARY operator.() THEN AND ONLY
THEN could we talk about situations where built-in operator. is invoked in
some situations, and overloaded operator. is invoked in other situations
DEPENDING ON THE RHS.

BUT

If people insist on making operator.() BINARY because they continue to
insist on SELECTING between built-in operator.() and overloaded operator.()
based on NOT ONLY the LHS, BUT ALSO the RHS, then I ask these people, please
tell me what the type of the second parameter to BINARY operator.() IS ????

ANSWER:

The RHS of a BINARY operator.() MUST BE a "reference to member"

BUT

The C++ language does not contain a concept of "reference to member" thus
no such binary operator.() COULD BE specified!  Because you cannot declare
the type of the second parameter.

THEREFORE:

I do not propose a binary operator.() because no such beast is possible
in the C++ language.  Please stop asking me for it.  Please stop using
it as a bogus argument against allowing unary operator.() to be overloaded
JUST LIKE OPERATOR->().

If YOU still believe that binary operator.() should be in the language then
YOU convince the committee to include "references to members" in the language.
ONLY THEN is a binary operator.() possible.  AND THEN, both unary and binary
operator->() and operator.() become possible JUST LIKE unary and binary 
operator&() are today possible.

Xref: sparky comp.lang.c++:11348 comp.lang.c:11451