Robustness of the built in associative array

[Sean Kelly]

Nick wrote:
> In article <e00v0m$te2$3 at digitaldaemon.com>, Oskar Linde says...
>> Hello,
>>
>> The latest "Implicit fn template instantiation" thread contains code 
>> that contains a hidden and possibly hard to find bug.
>> [...]
> 
> Good catch!

Indeed.  It seems roughly similar to how arrays are handled: in place 
modifications persist, but anything causing a realloc does not.  But the 
original should never be rendered unusable.

>> 2) Why even keep the builtin AA? With the addition of an opIn() 
>> overload, you could get *exactly* the same functionality from a library 
>> implementation
> 
> Nope, in fact, you couldn't. The kicker is that the builtin AA uses some syntax
> that is currently _impossible_ to duplicate in custom types. Eg. the following:
> 
> #  int[int] ii;
> #  ii[10]++;

Yup, not having a bona fide reference type in D is problematic.  Though 
you could always use pointers :-p

> I find it rather confusing and frustrating. In my current project I ended up
> making my own template AA to get around some of the deficiencies of the builtin
> type. Mostly I wanted to avoid double lookups, and easily allow custom hashers
> without encapsulating the key in a struct/class (think case-insensitive char[]
> keys.) The result was also faster and more memory efficient than the builtin AA.

This would also *almost* allow us to get rid of opCmp(Object) and 
opEquals(Object) in the Object base class, which would be very nice.  I 
definately do like having built in AAs, but I do find some of the 
consequences irritating.


Sean