C++ Logo


Advanced search

Re: [std-proposals] In re: Issue2157

From: Ryan Nicholl <rnicholl_at_[hidden]>
Date: Wed, 6 Dec 2023 15:50:32 -0800
I think the syntax is workable, but I would like the following things

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

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

Received on 2023-12-06 23:50:45