Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.lang.c++
Subject: Re: Improved switch statement
Message-ID: <781@auspex.UUCP>
Date: 22 Dec 88 09:12:50 GMT
References: <6590072@hplsla.HP.COM> <1106@etive.ed.ac.uk> <33528@bbn.COM> <1907@ogccse.ogc.edu> <574@redsox.UUCP> <9245@ihlpb.ATT.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 28


 >Not only must operator== be defined, but it must be defined to return
 >a scalar...

In fact, it had better return a Boolean value, or at least 0 for "not
equal" and non-0 for "equal"...

 >since there is no guarantee by the language (nor should there be, even
 >if it were feasable) that operator== is commutative with respect to it's
 >arguments, even if the arguments are the same type (let alone if the
 >arguments are of different types).  In effect, operator== must
 >*semantically* mean 'equal-to', in order for this extension to switch
 >to not appear to be kludgey.  This proposal doesn't fit in with the
 >rest of the language.

Well, offhand I'd think a program defining "==" operator that didn't act
like an equality operator would be a good candidate for an "Obfuscated
C++ Code" contest; I'd *strongly* suggest they pick some other operator.
Is there some good reason why one would want to define "==" as an
operator that didn't behave like a "comparison for equality" operator? 
If not, the feature might just have in its documentation

	*WARNING: this feature uses the class's "==" operator to do the
	comparisons; if this isn't an appropriate operator, don't use
	this feature.

and rely on the sanity and common sense of the programmer (a dangerous
assumption at times, admittedly).