On Wed, 6 Oct 2021 at 20:52, Keenan Horrigan via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
I need an array of uninitialized objects, and wrapping an object with a union is the only way to ensure an uninitialized object in the language as far as I know. When allocating an array of unions and then getting a pointer to the member, the constexpr interpreter treats it as a pointer to a single object when I need it as a pointer to contiguous objects. And again, as far as I can tell, this behavior is well-defined in the standard at runtime. The pointer of a union is pointer-interconvertible to a pointer to one of its non-static data members. I would try to put the array inside the union, but I need a runtime length for the array, so that's not gonna work either.

Well, treating an array of union-of-T as an array of T is UB at runtime, so it definitely isn't going to work in constexpr. A pointer to union is pointer-interconvertible to one of its members, but that member is not a member of an array (other than the trivial singleton array), so you can't perform pointer arithmetic on it.

Why not use std::allocator::allocate (followed by std::construct_at etc.)? That's constexpr since C++20.
While I would certainly enjoy more STL "wrappers" for reinterpret_cast's legitimate uses, the standardization process is slow, imperfect, and doesn't cater to every individual's needs. So allowing users to reinterpret_cast on their own in constexpr and the compiler ensuring that their code is well-defined would allow developers to take advantage of those well-defined use cases without the need to wait for the committee to standardize some magic wrapper or to just eventually reject the idea.

 That wouldn't have helped in this case. Do you have any more motivating examples?