Re: [boost] [hash] Extract module from functional + std::hash_combine

Subject: Re: [boost] [hash] Extract module from functional + std::hash_combine
From: James E. King, III (jking_at_[hidden])
Date: 2017-12-19 18:27:43

On Tue, Dec 19, 2017 at 10:48 AM, Peter Dimov via Boost <
boost_at_[hidden]> wrote:

> Daniel James wrote:
>
>> Hi,
>>
>> I'm planning to extract hash from functional into its own module, as that
>> will apparently break the circular dependencies that functional is part of.
>> Any objections? Also, any opinions on what the module should be called?
>> 'hash' might suggest a more general purpose hash function, so maybe it
>> should be called something more specific.
>>
>
> If we name the module 'hash' it's not hard to see that in the future it
> will be seen as the obvious home for implementations of MD5, SHA-*, and
> other hash algorithms (FNV-1a, cityhash...) which we do miss in Boost. So
> there will be pressure to add them, pull requests implementing them, and so
> on.
>
> The question is do we see this as a bad thing?
>

I asked the same question in this forum a couple months ago and there
seemed to be overwhelming response of "heck no we don't want to maintain
hash algorithms" for various reasons.  Boost.Uuid already has an MD5 and a
SHA1 hash algorithm in it, and other libraries in boost ALSO have a SHA1
implementation in them (Boost.Beast, Boost.Compute).  Seems silly to
maintain 3 copies of the same algorithm.  So I would be all for having a
Boost.Hash library that contained all of those plus a boost::container_hash
which would be the equivalent of boost::hash.  Given boost::hash exists
already, however, the namespace for Boost.Hash would need to be something
else?

Alternatively, if folks still don't want to provide hashing functions, here
are some suggestions:

container_hash
chash
pound (Boost.Pound) == Boost.# = hashtag = hash?

I think Boost.Hash would be confusing from a consumer perspective.  It
implies more than just one hash function.

- Jim