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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-12-05 08:54:53

Am 04.12.24 um 17:01 schrieb Peter Dimov via Boost:
> Claudio DeSouza wrote:
>> I tend to disagree. In my opinion even this:
>>
>>     hash.update( as_bytes( span{st} ) );
>>
>> Is better than this:
>>
>>     hash.update( v.data(), v.size() );
> Maybe.
>
> But the two cases with the current interface are consistent - you do the same
> thing for both vector and string - and the two cases with the "normal" span
> aren't.
>
> I would prefer a span-style interface where the two cases look the same,
> like this
>
>      hash.update( v );
>      hash.update( st );
>
> There'd be no questions here as to whether this is a usability gain compared
> to the current interface.
>
> (Ideally, in a hypothetical stdlib, .data would return a span and the above
> would be
>
>      hash.update( v.data() );
>      hash.update( st.data() );
>
> to make it explicit that we're dropping to a lower level interface, but one
> can't have everything.)

If the hash-algorithms would accept `span<const void>` (or <const char>) 
instead as the only `update` method (no need for overloads) we could have

 Â Â Â  hash_append( span{v} );
 Â Â Â Â hash_append( span{st} );

by accepting a templated span and casting it to the span-type expected 
by the hash-algorithms.
And/or a `hash2::span` that accepts any range-like in the ctor and doing 
the cast.

This would allow the save interface Claudio proposed while still having 
the same interface.

Or at least have it at the level of the hash algorithm as user 
interaction is through `hash_append`
provided by the library so that could make all necessary "spanification" 
if I didn't miss anything