ProtoObject and comparison for equality and ordering

[Steven Schveighoffer]

On 5/16/19 3:15 PM, Jonathan M Davis wrote:
> 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).

That's beside the point. You shouldn't call a non-const function on 
something that is const *or* immutable. Which is what druntime is 
currently doing.

For most intents and purposes, I think it should be fine to use 
non-const keys, as long as the keys are not modified while they are used 
as keys. You could, for instance, have a key that has some mutable data 
that doesn't affect the hash/equality. The language shouldn't impose 
restrictions that don't make sense for some cases, it just reduces the 
code you can write, even if that code would be perfectly valid.

-Steve