> I agree with not seeing the value of clear_padding. Even if there is a
> path to
> stably getting those bits cleared in order to make use of the non-padded
> value, it's fragile. But more to the point: what's the purpose of having a
> T
> with its padding bits cleared? The intent of clearing those bits must be
> that
> one wants to observe them, and in T itself, they can't. Therefore, I argue
> that the operation to clear the bits must transform the type into
> something
> else where the bits could be observed - that is a bit_cast operation.
>

The purpose is to do type punning both at runtime and at compile-time, with
the same code, in such a way that works if your type has padding bits too
(e.g. long double). And yes, bit_cast is the right tool for that.


> So should std::bit_cast() itself be amended to always clear the bits? When
> would we not want that?
>

That's certainly an option. I discuss that in
https://isocpp.org/files/papers/D3969R0.html#why-not-make-std::bit_cast_zero_padding-the-default-behavior

The issue is mainly that you get differences in behavior between compiler
versions (or even standards, if this is not a DR). This would be a
sharp edge. It also adds cost: an implementation of bit_cast is currently
permitted to copy over the bits from the source in their original state.
Clearing the bits would add cost to existing code. Without two separate
functions, you have no way of opting out of the cost.