If I remember correctly , std::array is an aggregate type that directly wraps a single data member of a built-in array type. Although it may not explicitly stated that it has the same layout as a C style array, this property should be deductible from other explicitly state clauses. For instance, since initialization of std::array is aggregate initializing the elements,
then there is no vptr or vbaseptr (because this would disqualify the type as an aggregate).

On June 30, 2023 9:07:54 p.m. EDT, 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.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals