On Wed, Oct 6, 2021 at 7:24 PM Jason McKesson via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Wed, Oct 6, 2021 at 3:52 PM Keenan Horrigan via Std-Discussion
> <std-discussion_at_[hidden]> 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