I think the syntax is workable, but I would like the following things
clarified:

Is std::array<T const, 0> permitted to be copy-assignable?

I think it should be allowed, but unsure.

Also, regarding,

In the case that N == 0, begin() == end() == unique value.
<https://eel.is/c++draft/array.zero#2.sentence-1>

The return value of data() is unspecified.
<https://eel.is/c++draft/array.zero#2.sentence-2>

There is also the requirement that array iterators are "contiguous
iterators", which I cannot figure out how to implement in a constexpr
context.

Solution 1. return nullptr, this is the current libc++ solution. The value
is not "unique".
Solution 2. A custom iterator for std::array<T, N>, the value is not a
"contiguous iterator".

I don't have a solution for this problem.

On Tue, Dec 5, 2023 at 2:04 PM Ryan Nicholl <rnicholl_at_[hidden]> wrote:

> By #2, do you mean that it does not contain any base or data members?
>
> I am a bit confused by this part, "unspecified empty aggregate type".
> Since I believe that only glibc currently uses an empty aggregate?
>
>
> On Tue, Dec 5, 2023 at 1:37 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
>> On Tue, Dec 5, 2023 at 4:03 PM Ryan Nicholl via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> I want to raise my personal concern around the proposed solution
>>> to Issue2157.
>>>
>>> I do not believe that std::array<T, 0> {{}}; should be required to be
>>> valid syntax. This prevents std::array<T, 0> from being implemented as an
>>> empty struct. It is also just logically inconsistent with an array that
>>> contains no elements. I believe this eliminates empty base class
>>> optimization and presents several other issues that I believe diverge from
>>> the 0 overhead principle. For this reason I think the solution ought to be
>>> reconsidered.
>>>
>>
>> (You're talking about LWG 2157
>> <https://cplusplus.github.io/LWG/issue2157>, "How does std::array<T,0>
>> initialization work when T is not default-constructible?".)
>>
>> There are two caveats you don't seem to be taking into account:
>> (1) No user-programmer ever should write `array<T,0> t = {{}};` —
>> `array`, like every other STL container and algebraic type, is intended to
>> be used with a single pair of braces `array<T,0> t = {};`. Yes, in
>> all present-day library implementations this relies on brace elision
>> <https://eel.is/c++draft/dcl.init.aggr#16.sentence-1>; that's okay.
>> (2) No library vendor implements `array<T,0>` as an empty type.
>>
>> Asking for `array<T,0>` to be "maybe empty, maybe not" would cause
>> (minor) pain for user-programmers. Asking for it to be "always empty" would
>> cause (major ABI-breaking) pain for vendors. The proposed resolution of LWG
>> 2157 seems to fix some infelicities in the current wording, without causing
>> pain for (1) any user-programmer or (2) any existing vendor. So it seems
>> like an improvement to me.
>>
>> –Arthur
>>
>