ProtoObject and comparison for equality and ordering

[Andrei Alexandrescu]

In designing ProtoObject and comparison for equality and ordering, we've 
assumed all class objects are supposed to be comparable (including 
ProtoObject themselves). That means code like this should always compile:

bool fun(C, D)(C x, D y) if (is(C == class) && is(D == class))
{
    return x < y && x == y;
}

That is, any two class objects should be comparable for equality (==, 
!=) and ordering (<. >, <=, >=). The decision whether comparison 
actually works for the types involved is deferred to runtime.

This is in keeping with Java, C#, and existing D where Object has 
built-in means for comparison.

However the question Jonathan M Davis asked got me thinking - perhaps we 
should break with tradition and opt for a more statically-checked means 
of comparison. The drawback is that some objects would NOT be 
comparable, which may surprise some users.

As a consequence, for example, creating hash tables keyed on certain 
types will not work. This is not quite unheard of as a type could 
disable opEquals. Also, by default struct types cannot be compared for 
ordering - they must define opCmp.

Should we go with a more statically-checked/imposed approach with 
comparison, or stick with OOP tradition? Ideas welcome.