ProtoObject and comparison for equality and ordering

[Andrei Alexandrescu]

On 5/15/19 4:09 AM, Jonathan M Davis wrote:
> 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.

It seems that could work real neat.

One thing that bothers me is inheritance. It seems to me most of the 
time just inheriting opCmp and opEquals does not work - they'd need to 
be overridden to account for the added state. However, sometimes they 
_do_ just work. So I'm in two minds on whether inheriting but not 
overloading those two should be an error or not.