Robustness of the built in associative array

[Oskar Linde]

Sean Kelly wrote:
> Nick wrote:
>> In article <e00v0m$te2$3 at digitaldaemon.com>, Oskar Linde says...

>>> 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

Consider the consequences of using a pointer in the above example. ;)

>> 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.

Is there any way to retain the syntax and ease of use of the built in AA 
with a library implementation allowing the flexibility of choosing:
- implementation
- hash function
- comparison function
?

/Oskar