Bad AA behavior

[BCS]

Dave wrote:
> BCS wrote:
>> void main()
>> {
>>     byte[char[]] set;
>>     char[] it = "it".dup;
>>     set[it] = 0;
>>     assert("it" in set);    // pass
>>     it[0] = 'a';
>>     it[1] = 'a';
>>     assert("it" in set);    // fail
>> }
>>
>>
>> This can't be correct.
>>
> 
> I believe it is correct because of the distinction between value and 
> reference types made throughout D. I don't find the behavior 
> inconsistent, although I've been bitten by it once or twice so I'd agree 
> that it's not always intuitive.
> 
> byte[char[]] set; // is an array of bytes indexed by char[]'s (a 
> reference type)
> 
> //set[it] = 0;
> set[it.dup] = 0; // this (obviously) will do what you expect
> 
> To get the behavior you suggest (and be consistent), then UDT's would 
> all have to have a copy ctor, either explicit or implicit. If implicit, 
> then how is the compiler supposed to do a deep copy on objects defined 
> like:
> 
> class C
> {
>     char* ptr;
>     //...
> }
> 
> ?
> 
> If manual memory management for D was the norm, then I'd say you have a 
> much stronger argument. But since GC is the norm. (and in part because 
> GC is the norm D also does away with copy ctor's) the current behavior 
> is correct, IMHO.
> 
> - Dave

Good point. But what about this

void main()
{
     byte[char[]] set;
     char[] it = "it".dup;
     set[it] = 0;
     assert("it" in set);    // pass
     it[0] = 'a';
     it[1] = 'a';
     assert(set.keys[0] in set);    // fail
}

Furthermore, once the underling data is changed, the member can't be 
accessed even to remove it.

set.remove(set.keys[0]); // has no effect

I'll admit that I don't known what to do with the object/struct case, 
but I think the current behavior isn't good.