Associative Arrays max length? 32bit/64bit
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Sun May 25 07:31:12 PDT 2014
On Sun, 25 May 2014 03:19:37 -0700, Marc Schütz <schuetzm at gmx.net> 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
More information about the Digitalmars-d
mailing list