On Sun, 25 May 2014 03:19:37 -0700, Marc Schütz <[email protected]> wrote:
On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer wrote:
Any object/struct that defines opCmp but not opEquals is broken, and
deserves to not work with AAs.
If this is the case, then it needs to be documented in
http://dlang.org/operatoroverloading.html (I'm not seeing it there), and
the compiler needs to make it an error.
In fact, you have to re-define opEquals, opCmp, and toHash all together to
get it to work with AA's properly. None of this is enforced. See this
here: http://dlang.org/hash-map.html
In particular this part:
"The implementation may use either opEquals or opCmp or both. Care should
be taken so that the results of opEquals and opCmp are consistent with
each other when the struct/union objects are the same or not."
But in reality, only opEquals and toHash need to be redefined together.
opCmp is not needed for hashing, especially with the current
implementation. The docs should be updated to reflect so once this is
fixed.
Somewhere on this newsgroup, I posted the rules that should happen, but
I'm too lazy to look them up. I will post them again:
1. Any type that has one of opEquals or toHash defined, but not the other,
should fail at compile time to become a key of an AA
2. Any type that has opCmp defined, but not opEquals, should fail to
become a key of an AA.
Note, although it is advised to always override these 3 functions for
consistency, I don't think violating this rule should be a compiler error.
But USING such a type as a key to an AA can rightfully be a compiler
error, as it is obvious such a thing will not operate properly, ever.
It's a trivial change to add opEquals when opCmp is defined. This
change should happen should happen. What pull request is it?
You mean have the compiler add it automatically?
No, I mean the runtime should rightfully penalize types that define opCmp
but not opEquals by working incorrectly with them (i.e. using opEquals and
not opCmp), similarly to how it currently works incorrectly with types
that define opCmp but not toHash or vice versa.
In other words, TypeInfo.compare should be nowhere in AA code.
-Steve
