According to the last meeting of the ISO C++ Commitee, bit-cast will be introduced in C++20 standard.
I know that
reinterpret_cast is not suitable for this job due to type allasing rules but my question is why did they choose not to extend the
reinterpret_cast to treat the object like it bit sequence representation and prefered to give this functionallity as a new language construct?
Well, there is one obvious reason: because it wouldn't do everything that
bit_cast does. Even in the C++20 world where we can allocate memory at compile time,
reinterpret_cast is forbidden in
constexpr functions. One of the explicit goals of
bit_cast is to be able to do these sorts of things at compile-time:
Furthermore, it is currently impossible to implement a
constexprbit-cast function, as
constexpr. Marking the proposed function as
constexprdoesn’t require or prevent
constexpr, but requires compiler support. This leaves implementations free to use their own internal solution (e.g. LLVM has a
Now, you could say that you could just extend this specific usage of
constexpr contexts. But that makes the rules complicated. Instead of simply knowing that
reinterpret_cast can't be used in
constexpr code period, you have to remember the specific forms of
reinterpret_cast that can't be used.
Also, there are practical concerns. Even if you wanted to go the
std::bit_cast is a library function. And it's always easier to get a library feature through the committee than a language feature, even if it would receive some compiler support.
Then there's the more subjective stuff.
reinterpret_cast is generally considered an inherently dangerous operation, indicative of "cheating" the type system in some way. By contrast,
bit_cast is not. It is generating a new object as if by copying its value representation from an existing one. It's a low-level tool, but it's not a tool that messes with the type system. So it would be strange to spell a "safe" operation the same way you spell a "dangerous" one.
Indeed, if you did spell them the same way, it starts raising questions as to why this is reasonably well-defined:
float f = 20.4f; int i = reinterpret_cast<int>(f);
But this is somehow bad:
float f = 20.4f; int &i = reinterpret_cast<int &>(f);
And sure, a language lawyer or someone familiar with the strict aliasing rule would understand why the latter is bad. But for the lay person, if it is fine to use
reinterpret_cast to do a bit-conversion, it is unclear why it is wrong to use
reinterpret_cast to convert pointers/references and interpret an existing object as a converted type.
Different tools should be spelled differently.