On Wed, Oct 6, 2021 at 7:24 PM Jason McKesson via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
On Wed, Oct 6, 2021 at 3:52 PM Keenan Horrigan via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
>
> > `reinterpret_cast` isn't good. It's a dangerous tool that we sometimes need, but its use should be contained. We shouldn't shove it into constexpr code just so that we can implement parts of the standard library in pure C++.
>
> First of all, not all my use cases for reinterpret_cast in constexpr are for implementing the standard library. I would probably doubt that the committee would find those use cases compelling, but they exist. Second, I'd agree that yes reinterpret_cast should in most cases not be used, however, as you said, it is something we sometimes need. Furthermore, the compiler would be required to detect the uses of reinterpret_cast that eventually lead to UB, so in constexpr code it would be necessarily safe on that front.

No, the compiler would be required to detect the uses of pointers that
*are UB*, not the things that led up to them. Given this code:

auto *pA = new A;
auto *pB = reinterpret_cast<B*>(pA);

The compiler would be required to realize that `pB` is "a pointer of
type `B` which points to an object of type `A`." Every piece of code
that uses pointers would have to check to see if the pointer points to
an object of the type it claims to point to. And it would only be
permitted to consider the code ill-formed if someone uses that pointer
in the wrong way.

Or we could just not have reinterpret_cast at compile-time.

That's already the case though. The compiler has to keep track of all of that in order to validate other kinds of code that you can write - like conversions from Base* to Derived*. 

There's definitely good reasons to have reinterpret_cast at compile time. One is implementing variant in a constexpr-friendly way in a way that doesn't involve a linear recursive chain of unions.

Barry