On 18 April 2012 12:44, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Daniel James wrote:
Even if I wanted to avoid SFINAE, I could probably write a type trait to detect them that doesn't rely on it.
By that I presume you mean that you would use a trait to dispatch to other functions/function templates that avoid the bool conversion problem, right?
Yes. I tried implementing both, and the SFINAE version was simpler than the traits version, so I've checked that in, and it seems to have worked without any issues on all of our test compilers. So I think I'll go with that. I haven't finished it yet, there are still some other built in types to deal with. I'm a little worried about changing the actual signature of the functions, the nice thing about a traits based version is that it would leave the API alone. Documenting this cleanly will also be an issue. It also clashes with the BOOST_HASH_NO_IMPLICIT mechanism because it makes the calls to template functions ambiguous. But if this works then it's redundant and fine to remove it.
I'm not sure if an implicit cast to a class' hash_function would always be considered safe. For example, someone might supply a lossy implicit conversion to std::string.
Implicit conversions cause all manner of problems. They are rarely a good idea, so I doubt you should worry about that. Besides, the function template can be specialized for such a class when the implicit conversion causes undesirable hashing.
I reread the original design paper and it deliberately supports implicit conversions to base, so maybe that should stay.