The `==' operator (Re: [nem-en] Nemerle 0.2.0 released)

[Michal Moskal]

On Mon, Sep 13, 2004 at 08:27:17PM +0200, Kamil Skalski wrote:
> On Mon, Sep 13, 2004 at 07:04:43PM +0200, Michal Moskal wrote:
> > On Mon, Sep 13, 2004 at 12:36:17PM -0400, Mark Friedman wrote:
> > > I'm curious about the rationale for having the '==' operator not
> > > fallback to reference equality?  I guess that it's not entirely clear
> > > to me what the '==' operator actually means in Nemerle.  
> > 
> > It works the same as in C#, that it is statically resolved whatever class
> > of the left or right parameter (or any base class thereof) has an overload
> > on ==. Some classes (like System.String or System.Decimal) have it.
> > 
> > However C# has an additional fallback case -- if there is no matching
> > overload, reference equality is used. That is == checks if objects on
> > both sides are physically the same.
> 
> This description is not clear. Why "or any base class thereof" doesn't
> refer also to System.Object? Object is base of all the classes, so
> simply the rule "whatever class of the left or right parameter (or any
> base class thereof) has an overload" is always satisfied. This way
> specification of how it works in C# is indeed clear and consitant - 
> it chooses the nearest possible overload. 

Nope, System.Object hasn't got == overload ;) It's special case as
usual.

> > Now this dual behavior is confusing for me -- what does it mean if I use
> > ==? It depends. It is often conceptual error to use == on classes that
> > don't overload it. In fact, after this was changed a few such errors was
> > spotted in the compiler. For me this fallback is against static type
> > safety.
> 
> And this is the only reason I can make up, why we should use "at least
> one parameter's type has exact oveload for ==" rule. From my experience
> and code found lately in compiler it is obvious that people like to
> use == as structural equality. The example it
> 
> if (x.GetType () == y.GetType ())  
> 
> where GetType returns System.Type object, which has no overload. I
> didn't look at the specs, but I doubt that GetType () MUST return the
> same reference for variables of the same type.
> 
> So my point is, that not consistency (our rule for == is much more
> complex than one from C#) but conservative typing are making us use
> this semantics. It's just forcing (maybe it should be a warning?)
> programmer to reconsider what kind of equality he is using.

Yes, it's conservative typing, not consistency :-)

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: ::: Logic is a nice contrast to the Real World. :: UL++++$ C++ E--- a?