I think it would be a foot gun if:
T1 A {};
T2 B = std::bit_cast<T2>(A);
static_assert(sizeof(T1) == sizeof(T2));
static_assert(alignof(T1) == alignof (T2));
assert(memcmp(&A, &B, sizeof(T1) ) !=0 );
It would violate the essential contract of what `std::bit_cast` is used for.
There might be an argument to be made that casting between types with a different layout of padding bits might not be a good idea.
But I wouldn’t go around changing behavior like this.
My 2cents.
From: Std-Proposals <std-proposals-bounces@lists.isocpp.org>
On Behalf Of Jan Schultke via Std-Proposals
Sent: Friday, January 16, 2026 08:50
To: C++ Proposals <std-proposals@lists.isocpp.org>
Cc: Jan Schultke <janschultke@googlemail.com>
Subject: [std-proposals] Fixing std::bit_cast padding bit issues
Hi, there are two issues with std::bit_cast, and I'd like to open a discussion for how to address these.
These two issues are closely related. The padding-wipe behavior can be added to
std::bit_cast mostly without cost to existing code because the padding-wipe only happens where currently,
std::bit_cast maps padding bits in the source onto non-padding bits in the destination. However, cost is added when casting to e.g. an
array of bytes; in that case, the bytes become indeterminate and the behavior is well-defined.
This presents us with a few options:
I think I prefer the second option, i.e. changing the behavior of
std::bit_cast to wipe padding, and adding another
std::bit_cast_indeterminate_padding function for the highly exotic case where you bit-cast to byte arrays and cannot afford the cost of
having some of the bytes zeroed. This is spiritually similar to making variables erroneous by default, and offering the
[[indeterminate]] opt-out.