A Fresh Look at Comparisons, Take 2

[Steven Schveighoffer]

"Janice Caron" wrote
> Observe that explicit member functions cannot be inherited, however,
> the inheritance mechanism is able to "jump over" an explict function
> when attempting to find a match, in order to match the next
> non-explicit function. I didn't explain that very well, did I? Let me
> show you what I mean by example:
>
>    class A
>    {
>        int f() { writefln("In A"); }
>    }
>
>    class B : A
>    {
>        explicit int f() { writefln("In B"); }
>    }
>
>    class C : A
>    {
>    }
>
>    A a = new A;
>    B b = new B;
>    C c = new C;
>
>    a.f(); // prints "In A"
>    b.f(); // prints "In B"
>    c.f(); // prints "In A"
>
> Here, the call to c.f() matches no function in C. It cannot match
> B.f(), because B.f() is explicit. But it /can/ match A.f(). And so it
> does. As far as objects of static type C are concerned. B's explicit
> functions might as well not exist.
>

Huh?  I think maybe you meant C to inherit from B?  If so I see what you are 
trying to explain :)

I don't really agree that opEquals or opCmp should not be inherited.  I 
think normal inheritance the way it is now is just fine.

You need to have opEquals in Object in order to support hashing.

The default opCmp should be redefined to throw an exception.  An alternative 
is that opCmp is defined in an interface.  Or you could do both.  The 
rationale is that opCmp doesn't have a default.  Some objects just cannot be 
expected to have a well-defined order.

-Steve