Sean Kelly <[email protected]> writes: > 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.
+1. If AA's insist on immutable object keys, I worry that that will force more folks to roll their own hashtables when working with large tables where the cost of duping all those keys actually matters. Also, I have found it useful on a number of occasions to key a hashtable with an object where the hash function is only computed on part of the object and the rest is mutable. Jerry
