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