Re: [hash2] Comments

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-12-06 22:56:01

On Fri, Dec 6, 2024 at 2:42 PM Ivan Matek via Boost <boost_at_[hidden]>
wrote:

> I was looking into if this could be wrapped into a nicer interface, that is
>  harder to misuse.
>

There could be merit here, and first we should identify who the users are.
These are the categories of "users" of Hash2:

1. Authors of a hash_append overload for a user-defined type
2. Authors of a HashAlgorithm
3. Authors of a Hash (the C++ named requirement described in
https://en.cppreference.com/w/cpp/named_req/Hash)
4. Authors of a foreign hash concept (something like a QHash or absl::Hash)

Let's analyze each case:

1. Authors of a hash_append overload for a user-defined type

There are uncountably many such users. They don't need to call result(),
and thus cannot misuse it.

2. Authors of a HashAlgorithm

There are a small finite number of these users, most of which will simply
be wrapping an existing cryptographic or non-cryptographic algorithm. They
need to implement result(), not call it, and thus cannot misuse it.

3. Authors of a Hash (the C++ named requirement described in
https://en.cppreference.com/w/cpp/named_req/Hash)
4. Authors of a foreign hash concept (something like a QHash or absl::Hash)

There are a small finite number of these users. We can probably identify
some of them. boost::hash comes to mind, plus the ones already written in
Hash2. We hope the calls to result() within the Hash2 implementation are
written correctly. The same cannot be said about future implementers; they
could in theory "misuse calls to result()." Authors of the C++ Hash named
requirement and similar non-standard named requirements are rare and we can
probably assume they know what they are doing, as most users are served by
utilizing the existing Hash functions such as boost::hash2::uhash which
work correctly out of the box and thus cannot end up with misuse of calls
to result().

Given that a limitless number of users already can't misuses result(), and
that the potential misuses of result() could only happen to a small number
of experts tasked with implementing named requirements, I'm not seeing the
value proposition for adding additional ceremony around the call. This
doesn't mean that result() doesn't have problems, and we should address
those directly instead of wrapping it.

Thanks