ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Thursday, May 16, 2019 7:53:45 AM MDT Steven Schveighoffer via 
Digitalmars-d wrote:
> On 5/15/19 11:51 PM, Andrei Alexandrescu wrote:
> > OK! I finally remembered why we went with the design "any two
> > ProtoObjects must be comparable". We should have a way to document this
> > stuff, I'd internalized it so much I'd forgotten the reason.
> >
> > It has to do with the way D implements built-in [hash]tables. They use
> > indirect calls via TypeInfo classes that essentially require the
> > existence of equality and hashing in class objects as virtual functions
> > with fixed signatures.
>
> Yes, but that can be redone. Basically the TypeInfo for an object uses
> Object.toHash expecting the base to be object (and BTW is calling this
> on a specifically non-CONST object, even though keys are supposed to be
> const!)

Really, they need to be immtable if you want to guarantee that they don't
change. Having them be const doesn't really buy you anything other than
ensuring that the AA implementation doesn't modify it (and that sort of
thing in druntime has a nasty habit of casting to get around such things).
If the key is not a value type, then other, mutable references to the data
could change it. So, either the key has to be immutable, or you have to rely
on other code not mutating the key via another reference.

- Jonathan M Davis