On 23 Jan 2026 15:51, Sebastian Wittmeier via Std-Proposals wrote:
> What advantage does a std::clear_padding() function with complicated
> rules (copying vs. reference) and ABI change have compared to the
> bit_cast_clear_padding suggested by Jan?

clear_padding does not require an ABI change.

> - it is easier for the compiler/optimizer to modify
> std::clear_padding() in place instead of doing a copy as with bit_cast
> (because bit_cast works on values before optimization)

I'm not sure what this means. I expect that the proposed
bit_cast_clear_padding would provide essentially the same optimization
opportunities as clear_padding+bit_cast would, if this is what you mean.

The advantage of having clear_padding separately is (a) it can be used
without bit_cast but with other functions operating on object
representation and (b) it doesn't require any significant changes to
bit_cast or introducing a duplicate bit_cast_clear_padding (which then
begs the question, which of the two bit_cast variants a user should use).

There were a number of use cases for clearing padding as a separate
operation presented throughout the discussion. Some examples that came
to mind:

- Portable and fast hashing that operates on object representation
rather than value representation. This can be useful for hashing structs
with padding in the middle.
- Portable ordering of objects with padding using memcmp. For example,
ordering of 80-bit long double, where NaNs are also ordered.
- Fast (de)serialization using memcpy and IO using read/write, where the
user doesn't want to leak data in padding bits.

Also, there is a case to be made that bit_cast should *not* be required
to modify input bits as this would be a wasted work if the user doesn't
consume those bits afterwards. I think, someone early in the discussion
mentioned that this would be considered a breaking change.

Conceptually, clear_padding is a separate operation to casting the
value, and I think it should be defined as such.

> - single responsibility: type casting vs. padding modification;
> bit_cast would do both; [OTOH perhaps those two go hand-in-hand, as
> only the new longer type gives meaning/representation to the padding
> bits; and it can be seen as an advantage to couple the two]

Single responsibility is good, so I take this point as a pro for
clear_padding.

> whereas std::clear_padding() has a lot of disadvantages,
>
> at the very least moderately complex (and possible bug-prone) rules,
> when padding would be preserved and when not.
Most of the necessary rules are already in place. The only thing in the
existing rules that need to change is bit_cast should be specified to
copy input padding bits into the output value representation bits
(whereas currently the standard only says that the resulting value bits
have unspecified values, not necessarily the same as input padding
bits). In practice, I believe, implementations simply copy input bits to
the result, so the change in the standard wouldn't really change
anything in practice.