Re: [boost] [Hash2] Result extension

Vinnie Falco wrote:

On Mon, Dec 9, 2024 at 8:43 AM Peter Dimov via Boost mailto:boost@lists.boost.org > wrote:

...there is an example of doing that here

https://pdimov.github.io/hash2/doc/html/hash2.html#example_result_ extension

I will argue that for all the cases where result extension is a valid use-case, that the caller is already committed to a specific hash algorithm. And in this case the hash algorithm can specify additional behavior for update() and result() with no reduction in the usability of Hash2.

In other words, no generic code should be able to rely on result extension. I don't think this is an improvement. It's much more ergonomic for end users to be able to rely on all hash algorithm features, so that code can be generic without fear of invoking undefined behavior. That's also why all algorithms are required to support specific forms of seed construction, instead of every algorithm providing its own random constructors (even though this better reflects what happens today). The current hash algorithm requirements reflect my view on what minimum functionality a hash algorithm should provide in 2025. It's true that this doesn't correspond to what traditionally has been provided.