On Fri, Jun 30, 2023 at 9:08 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Jun 30, 2023 at 8:34 PM Brian Bi via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Would folks be interested in a proposal to require std::array<T, N> to
> have the exact same layout as T[N], i.e., no padding before or after the
> internal T[N] data member?
> >
> > (The special case where N is zero would be excluded from the
> requirement, obviously).
> >
> > A lot of people are surprised when I tell them that the standard doesn't
> already provide this guarantee.
> >
> > I can think of some theoretical reasons why this would be useful, such
> as being able to serialize a T[N] and then deserialize it as std::array<T,
> N> using the `std::start_lifetime_as` function. However, I'd like to hear
> from folks here if they would actually benefit from this guarantee in a
> real application. If there's sufficient motivation, I'll write a paper.
>
> The principal motivation I have is `bit_cast`. You cannot `bit_cast`
> from/to language arrays, but you can do it to `std::array`... except
> that there's no *guarantee* that you can.
>
> You ought to be able to, for any trivially-copyable type `T`, perform
> `bit_cast<std::array<std::byte, sizeof(T)>>(some_t)` and be guaranteed
> that this will work. And vice-versa.
>

I agree that this should be guaranteed to work. But, why would you actually
need to do this?


> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*