Even if something is not marked constexpr, the compiler+optimizer can compute its result at compile-time.   With today's optimizer and even more so future ones, arithmetic computations and what bits keep their value is something the optimizers reason about. Any wrong assumptions can make the program slower or longer or destroy the program logic in unforeseen manners.   Any changes for the padding logic has to be cleanly defined for the abstract machine and performance effects on actual machines have to be considered.   The suggested change that padding bits always have to keep their bits once it is set, may be clean, but not very performant. But if it is done, it has to be done in the whole language and not just for one single function. That does not work.   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 16.01.2026 17:37 Betreff:Re: [std-proposals] Fixing std::bit_cast padding bit issues An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 16 Jan 2026 18:17, Jan Schultke wrote: > Yes, but it's entirely unrealistic to expect implementations to make > massive changes to how they handle padding bits, seeing that the current > model works reasonably well. To my understanding, LLVM does not even > have an object representation for objects during constant evaluation; it > is generated on the fly when you std::bit_cast. I think, at this point we're only discussing runtime. At least, the clear_padding function I proposed earlier was purposely not marked constexpr.