On Sat, Jan 17, 2026 at 11:13 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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