On 23 Jan 2026 14:20, Sebastian Wittmeier via Std-Proposals wrote:
> Would also (in your view of the updated abstract machine in regards to
> padding) a
>
> std::set_padding(f); // set all padding bits to 1
>
> work in principle?
>
> So f would hold and keep the actual padding bits? Or would it only work
> with zeroing the bits?

In principle, set_padding could exist and work similarly to
clear_padding. But I don't see much use for set_padding, so I'm not
proposing it.

Tracking only the "cleared"/"not cleared" flag for padding may be
cheaper in terms of the resources the compiler consumes during
compilation, compared to "cleared"/"set"/"unknown". But I suspect the
compiler vendors will want to leverage the bit pattern tracking
machinery they already have in place, and in this case the specific bit
patterns in padding become almost irrelevant. At least, all-zeroes and
all-ones are very wide spread bit patterns, so it is reasonable to
expect compilers to recognize and leverage them very efficiently. I'm
not a compiler developer though, so I may be wrong about this.

> If only clear_padding is required, the compiler could clear the padding
> at any time. And sometimes it is required to clear those, but in doubt
> it could just clear them, too.

Yes, that would be allowed, but since this would be not free
performance-wise, I don't think compilers would do that. We are
proposing the clear_padding function to tell the compiler when the
padding is important, precisely to let it continue to largely ignore it
in other contexts.

> If both instructions would/should work, it has to keep the current
> padding bits as actual information within the type representation and
> operations.

No. Again, the padding contents matter only when they are consumed by a
following operation, such as memcpy or bit_cast. Whether you set the
padding bits to 0 or 1 is not important in terms of language rules or
data dependency tracking.

When operations are defined only in terms of value representation (e.g.
assignments, reads and practically any core language operations), the
compiler may still ignore padding as it does today. And yes, it may not
preserve a previously cleared/set padding as part of those operations.