Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <71622@microsoft.UUCP>
Date: 1 Apr 91 22:17:11 GMT
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu> <4607@lupine.NCD.COM> <1991Mar25.154128.4138@world.std.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 46

In article <1991Mar25.154128.4138@world.std.com> wmm@world.std.com (William M Miller) writes:
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Summary: 
Expires: 
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu> <4607@lupine.NCD.COM> <1991Mar25.154128.4138@world.std.com>
Sender: 
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Followup-To: 
Distribution: 
Organization: Microsoft Corp., Redmond WA
Keywords: 

In article <1991Mar25.154128.4138@world.std.com> wmm@world.std.com (William M Miller) writes:
|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. :-)

Okay, I'll bite:

I claim one of those guiding principles ought to be that whenever we
have a chance to 1) change the definition to make the language more orthogonal, 
removing a special case "wart" WITHOUT negatively impacting existing
code, verses 2) leaving the language the same, arguing the change is not
worth the effort, that we should "almost always" make that effort.
IE the burden of proof ought to be on the supporters of the "wart", not
on the people who want to remove the unnecessary special case.

It may take a little extra effort to remove these "warts" from existing
compilers, but over the lifetime of the language, its going to make
10s of thousands of programmers lives easier.

----

Another second guiding principle ought to be:  The ANSI-C++ spec specifies
*language* not *implementation.*

----

And "my" third guiding principle would be, the ANSI-C++ specification
either calls out *one* behavior for a compiler regards a particular 
feature, or leaves *all* interpretation of that feature "implementation
dependent" BUT DOES NOT specify two contradictory *implementations*
either of which [but no other] is acceptible.  [IE either agree to agree,
or agree to disagree, but *don't* agree to try to lock out future 
implementations!]