AA key conversion woes

[Sean Kelly]

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.