ProtoObject and comparison for equality and ordering

[Andrei Alexandrescu]

On 5/16/19 9:53 AM, Steven Schveighoffer 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!)
> 
> 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.

Good reminder. Wasn't also the magical rebinding of immutable keys?

string[immutable int[]] t;
foreach (k, v; t) { ... }

Or/also something having to do with fixed-size arrays as keys?

string[immutable int[4]] t;
foreach (k, v; t) { ... }

We should document this institutional memory in a wiki somewhere.