Improve detection and enforcement of is_avalanching trait
First of all, thanks for making this awesome library!
Is your feature request related to a problem? Please describe.
The mechanism for tagging high quality hashes could be improved a bit, so it's easier to integrate in existing code bases.
Describe the solution you'd like
- I prefer to specialize
std::hash, but the primary templateankerl::unordered_dense::hashwhich falls back tostd::hashdoesn't currently propagate theis_avalanchingtrait. So it won't be detected unless hashes are moved toankerl::unordered_densenamespace. - In my project, all hashes are supposed to be high quality, but it's easy to forget to add the
is_avalanchingtrait. It would be nice to have arequire_avalanchingpolicy on the container that can be asserted at compile time. - An additional
assume_avalanchingpolicy sounds a little dangerous, but would avoid having to litter code withis_avalanchingtraits.
Describe alternatives you've considered
My approach for (2) is to wrap the default hash type:
template <typename Hash>
struct require_avalanching : Hash
{
static_assert(requires { typename Hash::is_avalanching; });
};
// alias with default policy
template <class Key, class Hash = require_avalanching<ankerl::unordered_dense::hash<Key>>, ...>
using hash_set = ankerl::unordered_dense::set<Key, Hash, ...>;
Hi @vmilea, these are all very sensible points. I'll see that I can fix all of them.
About (2), I'm thinking whats the best way to implement this is. E.g. I can provide typedefs for the maps in a custom namespace, or globally enable the check with a macro.
I then also need a way to opt out, so a way to specify that a hash is not avalanching (maybe with is_not_avalanching or something like that). That also needs to work when the hash can't be modified.
I think an extra template parameter similar to Bucket would suffice. The user can add typedefs as needed.
A basic enum may work:
enum class hash_policy {
assume_avalanching,
require_avalanching,
detect_avalanching,
};
But a struct HashAdapter would be more powerful. Then the user can create their own adapter, with the escape hatches they desire, even when a hash can't be modified.
To be clear: the HashAdapter wraps the hash, but is a distinct template parameter on the container. So if the user changes the Hash, the avalanching policy continues to be enforced. Unlike the "alternatives you've considered" code.