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 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.
So this discussion is only on which "concept that hashers must use".
If you mean this
template<class T> void update( std::span<T> sp );
then the reason to not use it is that you can't pass things like `string` and `vector<unsigned char>` and `char[65536]` directly because deduction will not work.
I'm not particularly fond of the user-facing syntax being
hash.update( std::span{buffer} );
instead of
hash.update( buffer ); Related to the above: Isn't the user-facing API the `hash_append` function and this update method is part of the concept for hash algorithms? And `hash_append` can massage the input into whatever that concept requires.
Given that I kind see that point why void*-size is acceptable, except for the new warning/safety-guidline against such pairs. If that should be adhered too (note that I no longer lean strongly either way) the interface could be defined using a SpanConcept: `void update(SpanConcept)` where `concept SpanConcept = requires(T t) { t.data(); t.size(); }` (Use of C++20 syntax only for illustration) So implementers are not required to support a particular span but to accept any span-like that `hash_append` passes to it. However I see the shortcoming that this would possibly exclude `template<typename T> void update(std::span<T>)` because `hash_append` might use `boost::span` which isn't(?) convertible to std::span (or whatever span type the hash algorithm accepts). So hash-algorithms need to use `template<class T> void update(T data_span)` exclusively, which isn't great either. --> void*-size is likely the most flexible and least burden for hash algorithm authors. If there is the way to silence the compiler warning in a reasonable way I don't see a reason against it.