On Fri, Mar 23, 2012 at 07:18:05PM +0100, Timon Gehr wrote: > On 03/23/2012 07:10 PM, H. S. Teoh wrote: > >On Fri, Mar 23, 2012 at 07:01:46PM +0100, Timon Gehr wrote: > >>Why do you not just do the conversion and then compute the hash, > >>even if the representation is the same? > > > >Because Andrei says that the .idup shouldn't be performed unless it's > >necessary (e.g., you should be able to lookup char[] in a > >string-keyed AA without incurring the overhead of an .idup each > >time). The conversion is not needed if the hash computation doesn't > >change and we don't need to create a new entry. [...] > > That does not apply to your example with double and int. (I'd argue > that actually the other overload should be chosen in that case, > because the conversion is implicit)
Sorry, I didn't understand that... which other overload? > For implicit .idup, one solution would be to compare immutable(Key) > and immutable(T). If they are the same, then the representation is the > same. Excellent idea! I didn't think about using qualifier collapsing to check for representation equivalence. Thanks! :-) I think this issue is now solvable: if a key is implicitly convertible to the AA key but it's *not* equivalent, then convert it first. Otherwise, convert it later via .idup or some analogous mechanism. template isEquiv(T,U) { enum isEquiv = is(immutable(T)==immutable(U)); } ... static if (is(InputKey : Key) && !isEquiv!(InputKey,Key)) // convert now else // convert later T -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous