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
>