On Wed, 15 May 2024 at 09:44, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, May 15, 2024 at 7:58 AM Jonathan Wakely wrote:
> >
> > Why would you want to hash the indeterminate padding
> > bits between members anyway?
>
>
> How about we add a new constexpr function to the standard library
> called "std::zero_padding":
>
> template<typename T> requires (!is_const_v< remove_reference_t<T> >)
> constexpr T &&zero_padding(T &&obj, bool const skip_tail = false)
> {
> // Step 1: Zero out the padding bits inside integer types
> // Step 2: Zero out the padding bytes between member variables
> // Step 3: If 'skip_tail' is false, zero out the tail padding
> // (must set to 'true' when used with 'no_unique_address')
> }
>
> With regard to Step 1, this is a throw back to the days when a 36-Bit
> integer was a 32-Bit integer with 4 padding bits -- so probably
> doesn't apply today.
>
> The hash algorithm could hash "__datasizeof(T)" instead of
> "sizeof(T)", which is why in the above function I give the option of
> skipping the tail padding.
>

Why would you want the md5sum for tuple<int, char> to depend on the
unspecified order of the two subobjects, and the unspecified number of
padding bytes? Given a custom String type, why would you want the md5sum of
tuple<String, int> to hash the bits of the String, which is probably a
pointer value, instead of the characters in the string?

Why not just visit each of the members in a defined order, say get<0>(t)
then get<1>(t), and hash each member? Wouldn't this be more sensible, more
portable, and more useful for other hashing algorithms that also want to
visit each member of a data structure?

Instead of inventing more complicated and less portable ways to access
every object as a bag of bits, why not follow the actually useful and
already existing practice of abseil and boost and others?