Re: [hash2] Difference from paper: HashAlgorithm interface vs. function object

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-12-11 17:31:40

Andrey Semashev wrote:
> Hi,
> 
> The HashAlgorithm interface defined in Boost.Hash2 is notably different from
> the one described in N3980 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html).
> Specifically, the paper defines HashAlgorithm as a function object, whose
> operator() is equivalent to Boost.Hash2's HashAlgorithm::update method. The
> function object also provides a conversion operator to result_type, which is
> equivalent to Boost.Hash2's HashAlgorithm::result method.
> 
> Is this discrepancy intentional and are there plans (on the paper authors' or
> the library authors' side) to eliminate it?

It is, yes.

> The paper discusses that the fact that a hash algorithm is a function object can
> be used to wrap it in std::function, which can be useful with pimpl idiom and
> for the purpose of type erasure. I don't think this will actually work, at least
> not as simple as the paper describes it, because std::function won't allow to
> extract the computed hash digest (i.e. you won't be able to call the type
> conversion operator on the wrapped function object). I think, the user will
> have to write some wrapper classes anyway to retain access to the wrapped
> hash algorithm.

That was more or less my line of thought too.

> However, this is still an interesting use case. Does Boost.Hash2 intend to
> provide utilities to address it?

As I already said, I had a type-erased wrapper on the to-do list, but decided
against providing one, for two reasons:

1. A type-erased wrapper can't provide a constructor, not even a default one.

2. The copy constructor of the type-erased wrapper would need to allocate
  and be potentially throwing. While this is not prohibited by the requirements,
  it's unlikely to be desirable.

You've already stated that you don't think copy construction should be
required. But copy construction is required by the current implementation of
hash_append_unordered_range.

What if we just drop support for unordered ranges? While I appreciate the
ingenuity of this Stalin-inspired design approach, I don't think that the
library should only require from the hash algorithms what the library uses
today. hash_append_unordered_range should be seen as representative
of what users may need to do with hash algorithms, and it clearly
demonstrates that sometimes, taking a copy of the hash algorithm is
needed.

What about solving both (1) and (2) by making construction and copy
construction optional requirements (along with result extension)?

That, too, is not what I would consider particularly user-friendly. Note that
we now have five properties (four constructors and one result retrieval
function) that can vary independently. This translates to 32 possible hash
algorithm interfaces.

No, what I prefer is for users to be able to rely on each of these five
properties, and for hash algorithm authors to be required to implement
them, instead of picking what to support and what not.