Wouldn't that then just make it std::span without the benefit of being able
to use std::dynamic_extent ? If contiguous memory is required, std::span
would be better to use.

I also didn't know until your email just now, so color me surprised. What
about augmenting to take two more arguments: std::array<T,N,O,S>
T - type
N - number of elements (or std::dynamic_extent like std::span takes)
O - offset of first element
S - stride (where S >= sizeof(T))

Then we can axe std::span and use std::array as the ur-array. Contiguous
memory would be guaranteed with a stride of sizeof(T), and an offset of 0
can make this behave just like T[] without worrying about where the first
object is. Having offset and stride available as constexpr data at compile
time would be super helpful. We would still be able to get views and
iterators from this without an issue.

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.
>
> I don't think implementations would actually have to do any work to
> conform to this requirement, so my only concern is about whether I can
> provide sufficient motivation to get this proposal through the committee.
>
> (Bonus: require std::array<T, N> to be pointer-interconvertible with its
> T[N] member, even when T is not standard-layout. This part of the proposal
> might be a bit more controversial, though; I'm not sure how hard it would
> be for implementors.)
>
> --
> *Brian Bi*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>