|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-09 18:19:28
Vinnie Falco wrote:
> On Mon, Dec 9, 2024 at 8:43â¯AM Peter Dimov via Boost
> <boost_at_[hidden] <mailto:boost_at_[hidden]> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk