ProtoObject and comparison for equality and ordering

[Steven Schveighoffer]

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!)

The TypeInfo_ProtoObject (which would be what we are talking about 
here), can use the same technique as structs -- the compiler writes an 
xtoHash function for it, and puts it in the TypeInfo as a function pointer.

> My thinking is, built-in hashtables are overdue for improvement anyway 
> so keeping compatibility with them isn't awfully motivating.

We need to redo builtin hash tables. As I understand it, the biggest 
hurdle is this feature of builtin hashtables which isn't exactly easy to 
do with our current operator overloading scheme:

int[int[int]] nestedAA;

nestedAA[1][2] = 3; // magically knows to create the intermediate AA if 
it doesn't exist.

-Steve