ProtoObject and comparison for equality and ordering
12345swordy
alexanderheistermann at gmail.com
Tue May 14 19:53:34 UTC 2019
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.
More information about the Digitalmars-d
mailing list