Re: [hash2] Formal Review Begins

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-12-13 08:20:25

> One of the things that puzzles me about this library is its intended
> purpose. "Types don't know #" was clearly about hash types for use in
> hash tables, which explained why keying the hashes was mandatory. But
> it is unclear to me why MD5, SHA-1, and other cryptographic hashes are
> present here;
> [...]
> I believe the HashAlgorithm concept is too overloaded. It _requires_
> that hashes be both keyable and extendable-output, [...]
> A user that wants to use this library with a hash
> that is not included here is going to be pushed to include
> functionality the hash does not provide and that they might not know
> how to achieve.

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?
The HashAlgorithm is provided by the user as an instance. How the users 
constructed that isn't relevant for the purpose of the library, is it?
To my understanding having support for seeds could be highlighted as 
best practice for specific use cases, but not as a general requirement.

I understand that the library provides ways to extract a hash out of an 
Algorithm.
So including `result_type` and `result` makes sense, although given that 
this is C++11 the former seems a bit outdated as it can be determined by 
the latter.

But besides that there are no requirements on HashAlgorithm relied upon 
by the library, are there?
For user convenience I can see `SeedableHashAlgorithm` as a subset of 
`HashAlgorithm` as a useful, additional concept to include in the library.
The library could provide traits to check a given type for a specific 
concept (when lacking C++20 concepts)
This would give users and hash authors more freedom in which algorithm 
is used.

Of course it could be stated, that all included algorithms conform to 
the `SeedableHashAlgorithm` concept, if they (meaningfully) are.