Associative Arrays max length? 32bit/64bit

[John Colvin via Digitalmars-d]

On Sunday, 25 May 2014 at 06:54:47 UTC, Steven Schveighoffer 
wrote:
> On Sat, 24 May 2014 21:39:14 -0700, H. S. Teoh via 
> Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> On Sat, May 24, 2014 at 06:05:49PM -0700, Steven Schveighoffer 
>> via Digitalmars-d wrote:
>>> On Sat, 24 May 2014 02:54:01 -0700, FG <home at fgda.pl> wrote:
>> [...]
>>> >Really? Then what does TypeInfo.compare(void*, void*) use? 
>>> >For
>>> >example here:
>>> >
>>> >    auto key_hash = keyti.getHash(pkey); Entry *e;
>>> >    /* ... */
>>> >    if (key_hash == e.hash) {
>>> >        auto c = keyti.compare(pkey, e + 1);
>>> >        if (c == 0) goto Lret;
>>> >    }
>>>
>>> You know what, you are right. I assumed it used keyti.equals. 
>>> This is
>>> a bug imo, since opCmp will be used, and opEquals will be 
>>> ignored.
>>> Just checking for opCmp == 0 is identical to opEquals, except 
>>> some
>>> types can define opEquals but not opCmp.
>>>
>>> But I don't know if it will get fixed. The whole AA runtime 
>>> has to be
>>> redone at some point.
>> [...]
>>
>> This has been argued over in a druntime pull before. I'm 100% 
>> for
>> changing the above line (and all other instances of it) to use
>> keyti.equals() instead. But that was shot down due to 
>> potential breakage
>> of existing code. :-( :-( Nevermind the fact that it probably 
>> breaks a
>> lot more *new* code than it ever will break old code... :-(
>
> Any object/struct that defines opCmp but not opEquals is 
> broken, and deserves to not work with AAs.
>
> It's a trivial change to add opEquals when opCmp is defined.

> -Steve

Perhaps I'm being naïve, but can't we just have a default 
compiler generated opEquals iff opCmp is defined and opEquals is 
not.