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