ProtoObject and comparison for equality and ordering

[12345swordy]

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.

I say go for statically-checked/imposed approach means of 
comparison. As matter as fact do it for deconstructor as well as 
other features. Currently I can't create a deallocate function 
for class in a @nogc safe context without resorting to 
workarounds and hacks involving hidden symbols. This is a major 
pet peeve of mine that I have with D for years, which makes me 
consider it a hobby rather an serious language.