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?  - 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)  - 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]   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.   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 23.01.2026 13:22 Betreff:Re: [std-proposals] Fixing std::bit_cast padding bit issues An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 23 Jan 2026 14:54, Sebastian Wittmeier via Std-Proposals wrote: > So you say clearing the padding would not necessarily have to survive > passing function boundaries? Yes, for passing or returning *by value*. Creating a copy of the object does not necessarily copy padding bits. Passing by reference does not create a copy, so it would preserve the padding contents. > IMHO that construct is quite shaky (for human reasoning and teaching), > if a type keeps the padding for the near future after clear_padding, but > does not keep it intact for assignments, calling functions, returning > from functions. This utility is not intended for wide usage. Contexts where padding is meaningful are fairly localized, but they do exist and are important. It is fine to require to be careful around these places. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals