ProtoObject and comparison for equality and ordering

H. S. Teoh hsteoh at quickfur.ath.cx
Thu May 16 16:24:34 UTC 2019


On Thu, May 16, 2019 at 09:11:48AM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, May 16, 2019 8:41:09 AM MDT Steven Schveighoffer via 
> Digitalmars-d wrote:
[...]
> > 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.

That's a good point.  So really, what matters is that once a key is
inserted into the AA, there must be no changes visible through .opEquals
(and possibly .opCmp) and .toHash.

Although TBH, that smells like bending over backwards to do something
that's ill-advised to begin with. If you're writing a custom type as an
AA key, why would you deliberately write it so that it has external
mutators and extra state?  If only part of the object is actually the
effective key, then it should be factored out into an immutable object
and *that* should be used as key instead of the entire object.


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

At the very least I'd appreciate a warning that a non-immutable key is
being used to create AA entries.  There have been a number of bugs filed
in the past, caused by "ghost" entries in the AA that exist when you
iterate but otherwise are inaccessible, because their keys have mutated
and no longer match the stored hash value in the AA.


> Either way, I completely agree that druntime shouldn't be casting away
> const.
[...]

Yeah, that has the potential of blowing up if we ever implement
compile-time AA literals that get put into ROM. (Very distant
possibility, though, granted.)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy


More information about the Digitalmars-d mailing list