ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Thursday, May 16, 2019 8:41:09 AM MDT Steven Schveighoffer via 
Digitalmars-d wrote:
> 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.

Well, as I said, druntime has a nasty habit of using casts to work around
problems. The type safety of druntime code in general is likely suspect as a
result. And that really should be fixed.

> 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.

I don't really care whether we require that the keys be immutable. My point
was that requiring const makes no sense, because it doesn't guarantee
anything that matters to the AA implementation. Either we require immutable,
or we don't care and let the user shoot themselves in the foot if they use a
mutable object and then mutate it, because requiring immutable is too
restrictive. Either way, I completely agree that druntime shouldn't be
casting away const.

- Jonathan M Davis