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

[Kamil Skalski]

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. 

> 
> 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.

Kamil Skalski