On Fri, Jun 30, 2023 at 8:59 PM Tony Basch via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>

No, because std::array<T, N> actually stores N objects of type T, while
std::span<T, N> only stores a pointer to N objects of type T.


>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*