On Saturday, 17 January 2026 07:58:47 Pacific Standard Time Jan Schultke wrote:
>
> People diligently checking feature-test macros is a very optimistic
> assumption. The issue is that if we only change bit_cast, then the function
> compiles either way, whether it has UB or the compiler is recent and it's
> well-defined. If you're forced to spell it std::bit_cast_zero_padding, it
> either compiles and does the right thing, or it doesn't compile.
That is the argument you should spell out.
But stemming from the same optimistic assumption that people know what they're
doing, I come to a different conclusion: it's better to fix the behaviour of
what people already use than to require them to know they must use a different
tool.
Hear, hear. I don't want new footguns in C++; I want us to get serious about fixing the old footguns.
We can also recommend that vendors backport the new behaviour to older
standards.
Yup. If `bit_cast` in C++29 is specified to clear padding bits, then all vendors will backport that behavior to older standards pretty much by definition. The alternative would be for vendors to support two different behaviors for __builtin_bit_cast indefinitely (both the new, correct behavior and the old*, UB behavior) and that's just not something any vendor would be willing to do — it's a cost without a benefit. They'll just update their implementation to do the new thing unconditionally. Notice that there's no good way to write a test for the old* behavior anyway. (According to Jan's argument, such a test could do literally anything!)
* — "old" meaning "current, C++26, status-quo"
–Arthur