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

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-12-06 11:13:57

6 décembre 2024 à 11:15 "Andrey Semashev via Boost" a écrit:

> A hasher must expose a common public interface anyway to be compatible
> with hash_append

This is stricter than what is actually required. hash_append can be made to 
work with hashers having a different interface, as long as they follow a concept 
known to hash_append / hash_update. This concept does not need to rely on
types defined by boost::hash2, the dependency is the other way (boost::hash2
must include a specialization for the interface of the hasher).

>, 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.

That is imho largely worth it. This also gives a lot more flexibility / room 
for evolution. There is an order of magnitude between the number of usages 
of the hashing api, and the number of hashers used in a project. Changing the
hashing api means changing every call to hash_append (resp hash_update). 
Changing the hasher concept only means changing a few files.

But, as i said before, you can even support multiple hasher concepts in
hash_append / hash_update, so changing the hasher recommended api can be made
while keeping old hasher api still working. Something that cannot be done if 
you talk directly to the hasher.

> 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. 

I don't suggest to make changes to specifically forbid such use. Just that
the nominal / advertised usage uses a thin wrapper (which, i believe, would
be fully inlined and not result in additional runtime cost).

> This would allow the user types' hash functions not depend
> on Boost.Hash2 and therefore

This is not required by what i suggest.

> make support for hashing more lightweight

I expect the wrapper to incur no additional runtime cost (over manual conversions 
that would be done at call site instead).

> and potentially compatible with std::hash2, if one ever comes to light.

I do not see how this is related. Actually, i think it's quite the opposite: 
by decoupling the user API from the hasher concept API, you should make it 
easier to  integrate new standards / requirements on either side. Or i'm
missing something obvious here.

Regards,

Julien