On Fri, Dec 6, 2024 at 2:42 PM Ivan Matek via Boost
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