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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-12-05 12:27:35

> And I don't want to force hash algorithm authors to have to include
> <boost/hash2/span.hpp>, because this would mean a physical dependency
> on Hash2. At the moment, you can define a hash algorithm without including
> anything from Hash2, or anything from Boost. And that's how it has to be.
But you are currently defining the interface of the hash algorithms:
 Â Â Â  constexpr void update( unsigned char const* data, std::size_t n );
My proposal is to define it as e.g.
 Â Â Â  constexpr void update(span<unsigned char const>);

I.e. to go range-safe from the start.
That would not depend on the hash library but on the chosen span 
library, which might be more acceptable.
However in C++11/14 this would require the Boost span, so I guess this 
is also off the table, unless the interface would be required to support 
span-likes
which could be done by users via templates and not require a specific 
span implementation.

But even with the current interface of "potentially unsafe" hash 
algorithms the `hash_append` could be written to accept only spans/ranges.
The proposed `hash2::span` would then only appear in the interface of 
the library, i.e. `hash_append`

My thinking is: If this is intended to push N3980 forward for inclusion 
in a future standard then I'd expect it to not use the "old-style" 
pointer+size-pairs but std::span readily available in the targeted standard.