Re: [boost] [hash] Turn on BOOST_HASH_NO_IMPLICIT_CASTS by default

Subject: Re: [boost] [hash] Turn on BOOST_HASH_NO_IMPLICIT_CASTS by default
From: Daniel James (dnljms_at_[hidden])
Date: 2012-05-12 04:28:41

On 18 April 2012 12:44, Stewart, Robert <Robert.Stewart_at_[hidden]> 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.