On Thu, Aug 17, 2023 at 4:21 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Aug 17, 2023 at 9:08 PM Lénárd Szolnoki wrote:
> >
> > foo(a, pretend_is_std_array(a.arr)); // breaking the aliasing
> > assumption here
>
>
> I'll get to the point here:
>
> How about we explicitly write in the C++26 Standard that T[len] and
> array<T,len> are ABI-compatible,

Have you looked at the existing ABIs to see if this is viable? Because
in order for this to even be *considered*, then the following must be
true today:

```
struct A
{
  char ca1[3];
  char ca2[3];
};

struct B
{
  std::array<char, 3> ca1;
  std::array<char, 3> ca2;
};

static_assert(sizeof(A) == sizeof(B));
```

If any C++-supporting platform has an ABI such that a struct
containing only an array does not *always* have the same size (and
alignment) as the array itself, then what you're suggesting is an
ABI-break. And that's... bad.

> and also provide two functions:
>
> stdarray_to_array
> array_to_stdarray
>
> , both of which return a reference to an object that doesn't
> malfunction where you have anti-aliasing optimisations.

Um, no. While I appreciate the idea behind making `std::array`
isomorphic with language arrays, *this* suggestion is something that
should never happen.

If the two types are isomorphic, they should still be *different*
types. There's no reason to allow them to alias like that. If you want
to convert between them, use a `bitcast` (or rather, an array-based
version of the same idea).