ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Tuesday, May 14, 2019 6:24:58 PM MDT Seb via Digitalmars-d wrote:
> On Wednesday, 15 May 2019 at 00:08:10 UTC, Andrei Alexandrescu
>
> wrote:
> > On 5/14/19 12:36 AM, Seb wrote:
> >> On Tuesday, 14 May 2019 at 21:06:05 UTC, Mike Franklin wrote:
> >>> On Tuesday, 14 May 2019 at 20:36:08 UTC, Eduard Staniloiu
> >>>
> >>> wrote:
> >>>> Should `opCmp` return a float?
> >>>>
> >>>> The reason: when we attempt to compare two types that aren't
> >>>> comparable (an unordered relationship) we can return
> >>>> float.NaN. Thus we can differentiate between a valid -1, 0,
> >>>> 1 and an invalid float.NaN comparison.
> >>>
> >>> Seems like a job for an enum, not a float or an integer.
> >>>
> >>> Mike
> >>
> >> +1 for enum. As far as I can see you only have four actual
> >> states:
> >>
> >> lower, equal, higher, nonComparable
> >
> > This won't work because the result of opCmp is compared against
> > zero. Using a floating point number is likely to be more
> > efficient.
>
> A DIP should cite real evidence/data though.
>
> Also, note that all other cases except comparing against NaN
> require more instructions with a floating point number:
>
> https://d.godbolt.org/z/lwzBVn

Except that this DIP doesn't need to define opCmp's signature - at least not
if it's not including interfaces in the design. The rules for opCmp's
signature on classes should be able to be the same as it is for structs.
Classes derived from a class that defines opCmp will be restricted by the
signature on the base class, but the base class should be able to define an
opCmp the same way that a struct would, meaning that any spec changes that
we might want to make about what opCmp returns or accepts should be able to
be completely separate from this DIP.

- Jonathan M Davis