ProtoObject and comparison for equality and ordering

[Patrick Schluter]

On Tuesday, 14 May 2019 at 19:34:12 UTC, Andrei Alexandrescu 
wrote:
> 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.

The idea is to determine if traditional OOP didn't do it 
statically because they couldn't or because it was for a sound 
semantical reason.
A lot of runtime processing of Java and C# are done that way 
because the language does lack the capability to do it at compile 
time.
I don't have specifically the answer here, but I think that is 
one question that has to be evaluated here.