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

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-12-06 07:30:10

Le jeudi 05 décembre 2024 à 12:06 -0800, Vinnie Falco via Boost a
écrit :
> On Thu, Dec 5, 2024 at 5:11 AM Joaquín M López Muñoz via Boost <
> boost_at_[hidden]> wrote:
> 
> > You can define the interface of update as accepting a templatized
> > arg with
> > span-like semantics.
> > 
> 
> This could work. Instead of writing:
> 
> Â Â Â  h.update( span );
> 
> You instead write:
> 
> Â Â Â  boost::hash2::update( h, span );
> 

+1 on this approach.

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

I think it should evolve into something more like :

* a concept that hashers must use
* a public api for hash users

This means that for the library user, the hash object would basically
be an opaque type, only accessed through calls like
boost::hash2::hash_append(h, X) or boost::hash2::update(h, Y).

The public api can then use a set of overloads for Y to anything we
want to support (the multiple needed span<X>, a pair of pointers, a
pointer + a size, etc.). That burden is left out of hash implementors.

> The signatures for update can be conditionally compiled based on C++
> version, availability of boost::span, or it could be a function
> template based on a span-like concept. 

+1

> Hasher's update signature would remain as 
> (void const*, std::size_t ). 

Or, hasher's signature can be selected through a set of supported ones.

I'm not convinced by the ”hash writer shall not depend on boost::hash2”
argument, but if that really matters then it's technically doable
without forcing the use of the pointer + size pair for hash
implementors.

Regards,

Julien