Dominique Devienne
FTR, I tend to lean on Joaquín's side of the argument. If the provided explicit Hash/Pred template parameters of unordered_set do provide overloads for compatible keys, then it's "by design" that find() should use them.
If previous code that was relying on an implicit conversion to key_type starts using added overload on Pred/Hash, this simply means that the container designer made this choice explicitly, and I don't see why that a bad thing. After all the overloads were added for avoiding the key creation, which is exactly what I was trying to do here.
The problem James points to is not the one you describe, but the following: imagine Hash and Pred are not overloaded and another_type is a type implicitly convertible to key_type (in the example given by James, key_type=std::string, another_type=const char*). Without compatible key extensions, the code another_type x=... cont.find(x); is equivalent to another_type x=... cont.find(key_type(x)); But if find is templatized to accept compatible keys, then cont.find(x); will not trigger the implicit conversion to key_type, instead, every internal expression involving invocations to the Hash and Pred internal objects with x as argument will trigger the conversion. The net effect is that we pass from one implicit conversion when invoking find() to multiple implicit conversions inside find() code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo