Robustness of the built in associative array

[Hong]

This is just a perfect demonstration of the problem with D value types. A way to
solve this would be to extend the inout keyword to function return and
variables, such that [] would look like:

inout T opIndex(size_t i)

Hong

In article <e0169e$25hq$1 at digitaldaemon.com>, Sean Kelly says...
>
>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