ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Wednesday, May 15, 2019 4:51:11 PM MDT Andrei Alexandrescu via 
Digitalmars-d 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 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.
>
> So if we go with a statically-driven solution we lose hashtables keyed
> on any class not derived from Object. That would be awkward but
> hopefully acceptable until we have good containers (which are becoming
> possible only now with copy ctors and the upcoming __RefCounted type in
> druntime).
>
> A possibility to bridge us is to create a wrapper struct:
>
> struct HashKey(T) if(is(T == class)) {
>      private T payload;
>      bool opEquals(HashKey rhs) { ... }
>      size_t toHash() { ... }
>      alias payload this;
> }
>
> Inside the implementations introspection would be used to figure out how
> type T chose to implement comparison and hashing.
>
> My thinking is, built-in hashtables are overdue for improvement anyway
> so keeping compatibility with them isn't awfully motivating.
>
> Satisfactory or not?

I didn't realize that that was quite what the built-in AAs were doing, but I
was aware that their implementation isn't templatized, so I didn't expect
them to work with any classes not derived from Object without them being
improved. Either way, that does seem like a good workaround, and I certainly
wouldn't want to hurt what we're doing to improve classes because of
internal issues with our AA implementation.

Having built-in AAs is nice, but given all of the problems that we've had
with their implementation over the years, I'm inclined to think that having
them built into the language was ultimately a mistake anyway. We probably
should figure out how to make AA literals work with user-defined types
(without actually creating a built-in AA) at some point here, since that's
the really the only thing that built-in AAs can do that a user-defined hash
table type couldn't.

- Jonathan M Davis