IMHO boost::hash is perfect, in every respect. Follow that (including all the missing functionality in std::hash - particularly ADL-friendly hash_value()) and you won't go wrong. #include <hash> is fine by me. If we ever want any other kind of hash, surely is could go into #include <md5> or #include <sha256> etc. until std::hash >= boost::hash, it's not useful. In addition, I would propose (I am sure I'm not the first!): namespace std { template<class T = void> struct hash { ... }; template<> struct hash<void> { template<class T> auto operator()(T&& arg) const { return hash_value(arg); // ADL to the rescue } }; } and then: template<class K, class V, class H = std::hash<>, class E = std::equal<>> struct unordered_map; // std::equal<V1 = void, V2 = void> should of course compare any 2 comparable things Which finally makes unordered_map declarations sane. Whoever decided to downgrade boost hash before solidifying its uselessness in the c++11 standard? Anticipating: but but, backward compatibility... Answer: nostalgia is the death of innovation. Look forward my son... On 19 December 2017 at 14:31, Daniel James via Boost <boost@lists.boost.org> 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.
Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost