On Apr 17, 2012, at 11:41 AM, H. S. Teoh wrote: > > 2) Where things get hairy is when non-trivial keys are stored. Take > arrays for example. If the user declares int[int[]], then we need an > .idup so that we can store the key as immutable(int)[] (or should that > be immutable(int[])?). But now if the user passes in an int[] key, we > will need to .idup it in order to store it. This is acceptable, but what > should .keys return? If I were the user, I'd expect int[][], but since > we can't implicitly convert immutable(int)[] to int[], we need a .dup > for each key. Which introduces unnecessary overhead, since for the most > part the user doesn't need to change the keys anyway. But handing back > immutable(int)[][] from .keys will break a lot of existing code.
I'm inclined to say that if a reference type is used as a key to an AA, the user either has to promise not to change (assumeUnique) it or explicitly .idup it himself on insertion.
