Re: [hash2][review] Early review (due to holidays)

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-06 10:15:22

On 12/6/24 12:22, Julien Blanc via Boost wrote:
> 6 décembre 2024 à 09:31 "Alexander Grund via Boost" a écrit:
> 
> 
>>>  The proposed library currently consists of two things :
>>>
>>>  * a concept that hashers must use (for hash implementors)
>>>  * an hash_append helper to ease the use of hash functions with objects
>>>
>> As far as I understood this is exactly how the library is implemented:
>> It is not `boost::hash2::update( h, span )` but 
>> `boost::hash2::hash_append( h, {}, span )` but thats minor.
> 
> I have a different understanding.
> 
> Quoting the doc, “This library addresses two major use cases: hashing 
> an untyped sequence of bytes, and hashing C++ objects.”.
> 
> But for the former, the library relies on the user to directly call the
> hasher object update function. This is the part i don't feel comfortable,
> with, i think a hasher completly opaque for the user of the library would
> be a better design. That's just a minor change in term of implementation.

A hasher must expose a common public interface anyway to be compatible
with hash_append, and at this point why not use the interface in the
user types hash functions directly? What value a free hash_append
function would bring? The only thing that comes to mind is it could have
a more flexible interface, as Vinnie suggested, to keep the hasher
interface minimal, but that's about it.

I do think though that whether or not a free hash_append function is
provided, using the hasher directly through its public interface should
be allowed. This would allow the user types' hash functions not depend
on Boost.Hash2 and therefore make support for hashing more lightweight
and potentially compatible with std::hash2, if one ever comes to light.