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.

The return value of data() is unspecified.

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@google.com> 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@gmail.com> wrote:
On Tue, Dec 5, 2023 at 4:03 PM Ryan Nicholl via Std-Proposals <std-proposals@lists.isocpp.org> 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, "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; 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