On Saturday, 17 January 2026 11:17:04 Pacific Standard Time Jan Schultke wrote:
> > I would especially advocate against making it a *compile* time error,
> > because
> > the code may have been constructed in such a way that it never gets
> > executed
> > (it was indeed unreachable). Making it a compile time error would turn
> > perfectly well-defined-behaviour code into a hard error without a
> > solution.
>
> By the same logic, you could argue that an implicit conversion from std::map
> to std::to_chars_result should compile because it's possible that the user
> put it in an if (false) statement, so while it's complete nonsense, it may
> not matter. It's widely understood that when the user does something that's
> known to be a mistake at compile time, we don't tolerate it just because
> execution may not reach the affected area.

Not exactly. If the code doesn't compile today, then there's no code doing
that.

You're proposing that we disallow something that is currently allowed to
comiple, albeit something that should never actually get executed. That's the
definition of UB.

> If you can actually guarantee that the degenerate form of std::bit_cast you
> have written is never executed, if constexpr or #if can eliminate it just
> fine.

It might be a runtime decision. I can't come up with a valid explanation of
why it would be, as any type of reflection that would allow it to know that it
would be UB should be something known at compile time. But I can't exclude the
possibility.

> I agree that it would be convenient to have a solution immediately, but the
> overall design is always more important. In the overall design, if you
> changed the existing bit_cast, you would add cost that is impossible to opt
> out of, and you would break the intuition that bit_cast does not change any
> bit values. It remains to be seen whether LEWG thinks those problems
> outweigh the "we need a fix now!" factor.

I do agree we need a clean solution, not something that we'll look back and
wonder why it's so clumsy.

But with that in mind, I again come to a different conclusion: why we need two
functions, one which works for all types, and one that works only between no-
padding types or when the destination is a byte array?

> > But my counter-argument, weak though it may be, is that no one could have
> > meant to use those indeterminate-state bits. Copying them unmodified
> > serves
> > little purpose.
>
> Leaving them indeterminate leaves the user the freedom to overwrite them,
> ignore them, or to propagate them in their indeterminate state. Having
> those options without any forced added cost is clearly useful.

Indeed. I just don't think this benefit outweighs the advantages of having them
always cleared, and the long-term cognitive load of the library.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.