Implicit conversions for AA keys

[H. S. Teoh]

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