This is what I've scribbled so far as a list of to-do items:
- add hash_append_range taking a range - add a "provider" argument (providing the hash_append API) to tag_invoke - example of hashing boost::json::value - maybe change argument of tag_invoke to take the value by pointer, rather than by reference - maybe expose has_tag_invoke to users so they can specialize - make byte sequence seed constructor take `void const*` as well - change get_integral_result to take a Hash, instead of h.result(), so that it can invoke result() more than once - a user-accessible way to test whether a hash algorithm conforms to the requirements - add a variadic hash_append overload - hash_append_unordered_range: use more than 64 bits for intermediate hashes (uint64_t[4]); improve somehow https://lists.boost.org/Archives/boost/2024/12/258643.php - acknowledge https://github.com/HowardHinnant/hash_append - in documentation, focus more on the std::hash case, rather than on the md5sum case - in FNV-1a byte seed constructor, include the seed size - change block_size to std::size_t
This looks correct to me. One thing worth exploring in addition to a concept check for an existing hash algorithm would be an adaptor to allow non-conforming implementations to still be used. Multiprecision offers a skeleton class[1][2] to allow other backends to work within our requirements. This may lessen the consternation surrounding your concept by allowing existing (and potentially certified) implementations to be used. The cost of adapting say a FIPS 140-2/3 certified hash algorithm to your concept is considerable in both time and USD. Matt [1] https://www.boost.org/doc/libs/develop/libs/multiprecision/doc/html/boost_mu... [2] https://github.com/boostorg/multiprecision/blob/ad1ee2a9a8daf6fee2583f4dd98a...