Alexander Grund wrote:
That is actually a good point: Why are those requirements on the HashAlgorithm concept at all?
The library is (mostly) about allowing to hash types, i.e. the framework surrounding `hash_append`. I understand that a specific way (currently being discussed here on the list) of construction is required for implementing `hash_append` for unordered containers.
But besides that, why does the library require specific constructors at all?
Simplified, this asks "if we ignore the use cases that require seeding, why does the library require that the hash algorithms support seeding?"
For user convenience I can see `SeedableHashAlgorithm` as a subset of `HashAlgorithm` as a useful, additional concept to include in the library.
I've already answered this a few times. It's more ergonomic if all hash algorithms support a consistent interface. This allows writing generic code that can work with any algorithm. It allows switching from one hash algorithm to any other without breakage. It also allows switching from unseeded use to seeded use, or from use with uint64_t seed to use with a byte sequence seed, without breakage regardless of the chosen hash algorithm. The idea here is to make switching from a less secure use to a more secure use easy and painless.