std::array is a wrapper for an array!

Contents

1. Introduction

The std::array class template has established itself as a de-facto replacement for "builtin arrays" or "C-style arrays" in many code bases. This also means that it is frequently taught to novice programmers, with an explanation along the lines of:

std::array is just a wrapper for a C-style array:

template <typename T, size_t N> struct array { T __array[N]; // ... }

While this explanation is not correct for zero-length std::arrays, it does match how the template is implemented in every standard library for N != 0, and there is very little reason not to implemented it in this obvious fashion.

1.1. What the standard says

The actual specification of std::array is not so simple, and is a combination of multiple constraints on the implementation:

• It is a class template, a contiguous container ([array.overview] paragraph 1), and a reversible container (with an exception; see [array.overview] paragraph 3), and it meets some requirements of a sequence container.
• It can be list-initialized with up to N elements whose types are convertible to T ([array.overview] paragraph 2). This is obviously not exhaustive; initialization with {} or {other_array} should also be possible.
• It is a structural type if T is a structural type ([array.overview] paragraph 4), and therefore, also a literal class type in that event.

Additionally, while this does not strictly specify anything about the layout, some helper functions in the standard library de-facto rely on it. Take [array.creation] for example:

template<class T, size_t N> constexpr array<remove_cv_t<T>, N> to_array(T (&a)[N]);

Mandates: is_array_v<T> is false and is_constructible_v<remove_cv_t<T>, T&> is true.

Preconditions: T meets the Cpp17CopyConstructible requirements.

Returns: {{ a[0], …, a[N - 1] }}

The use of double braces in the Returns specification would be nonsensical if std::array was not "a wrapper for an array".

1.2. What the standard does not say

Notably, there are quite a couple of guarantees that are absent.

Such an implementation technically satisfies all the requirements for std::array, but

• copying the array would not be a constant expression,
• std::array would not be trivially copyable for any type, and
• its size and alignment would be much greater than that of T[N].

2. Motivation

It seems like the vagueness in the specification serves no practical purpose; it is unclear what implementations could do with the additional freedom, other than pranking their users. It would be beneficial to the C++ community if the simplified explanation in §1. Introduction was what the standard actually said.

A stricter specification would provide additional useful guarantees such as std::array<T, N> being trivially copyable when T is trivially copyable. This is relevant to use cases like std::bit_cast<std::array<std::byte, sizeof(x)>>(x), which technically rely on implementation details, not on standard behavior.

2.1. Isn't this a waste of time?

While it could be argued that only a malicious implementation would violate our user expectations as in §1.2. What the standard does not say and it is therefore time-wasting to restrict std::array any further, it would be unusual for WG21 to shy away from standardizing universally existing practice and to recommend users to rely on non-standard implementation details, simply because those implementation details are widespread. If the remaining implementation freedom can only be used for evil, perhaps we should not grant it.

3. Design considerations

While the specification for arrays of nonzero length is rather obvious, it is unclear how many guarantees we want to provide for zero-length arrays. For example, should std::array<std::string, 0> be trivially copyable, even though std::string is not?

Within [array.zero], there are some long-standing issues going back to 2012. LWG has visited this subclause many times in [LWG2157], but never fully completed a solution. This work has been absorbed mostly unmodified into §5. Wording.

3.1. Zero-length std::array status quo

The zero-length case is also where we see some implementation divergence in size and alignment of the array. The following table shows how major standard libraries implement zero-length std::array.

3.1.1. Conclusion

Generally speaking, it is desirable if a zero-length std::array behaves as similarly to a regular std::array of the same element type. libc++ is the only implementation that does this well. The "greatest common denominator" between these implementations should be standardized, which is:

• std::array<T, 0> is trivially copyable if T is.
• std::array<T, 0> is assignable if T is.
• std::array<T, 0> has size and alignment at most that of T.
• std::array<T, 0> is not an empty class.

Without breaking ABI, that implementation would look something like:

3.2. Trivial copyability of zero-length arrays

Whether a type is trivially copyable has ABI impact. It may change whether the type is passed via register or one the stack, and so we cannot mandate any change to this behavior without breaking ABI.

For MSVC, a std::array<int,0> is trivially copyable, but a std::array<std::string,0> is not. This seems reasonable; there is no strong motivation for making arrays trivially copyable even if a nonzero variant of the same array wouldn't have been. In fact, it could be argued that this is surprising and inconsistent.

3.2.1. Conclusion

Mandate that std::array<T,0> is trivially copyable if T is. Otherwise leave this up to implementations.

3.3. Double-brace initialization for zero-length arrays

Note that we need to make double-brace initialization like std::array<int, 0>{{}} valid to make generic programming easier. It is plausible that we perform this when expanding an empty pack like: std::array<int, sizeof...(args)>{{ args... }}.

Making this valid requires either some non-static data member, or a base class. An empty base class would make the array as a whole an empty class, and this would be an ABI break, so it is out of the question.

3.3.1. Conclusion

Standardize the existing practice of having a non-static data member which enables double-brace initialization.

3.4. Problematic iterator requirements for zero-length arrays

[array.zero] paragraph 2 specifies:

In the case that N == 0, begin() == end() == unique value. The return value of data() is unspecified.

Firstly, it is unclear whether this "unique value" is meant to be unique per object, unique for each invocation, etc.

Secondly, this requirement was never implemented by any compiler and it is too late to fix now. Note that MSVC STL, libc++, and libstdc++ all use T* as an iterator type. Considering that, a possible implementation looks like:

However, this would require std::array<T,0> to be at least one T large, and it is only a single byte large for libstdc++. Changing the size of the type would break ABI. The only way to conjure up a T* out of thin air would be to use reinterpret_cast, but that would not work in constant expressions.

3.4.1. Conclusion

Delete the uniqueness requirement. Without specifying anything special for zero-length arrays, it still acts as an empty range, and begin() == end() is true, which is all we really need.

3.5. std::array<T,0>::front() is std::unreachable()?!

std::array<T, 0>::front() is entirely undefined, making it equivalent to std::unreachable(), which feels out-of-place especially following C++26, where front() normally has a Hardened preconditions specification.

Note that deleting front() and back() for zero-length arrays is not feasible because of (existing) code along the lines of:

It is quite plausible that std::array<T,0>::front() is called in code that is logically unreachable, so it should not result in a compiler error, which would be the consequence of = delete;.

3.5.1. Conclusion

Make front() and back() always result in a contract violation, as if they had Hardened preconditions that are always violated. However, if the implementation is not hardened, these functions should simply terminate instead of being another spelling for std::unreachable().

4. Impact on implementations

Existing implementations of std::array are virtually unaffected. One exception to this is that the behavior of std::array<T, 0>::front() is no longer undefined; see below for specifics.

5. Wording

The following changes are relative to [N5008].

5.1. [array.overview]

Change [array.overview] paragraph 1 as follows:

Change [array.overview] paragraph 2 as follows:

Change [array.overview] paragraph 3 as follows:

Delete [array.overview] paragraph 4:

Change [array.overview] paragraph 5 as follows:

5.2. [array.zero]

Delete all paragraphs within [array.zero]:

Insert new paragraphs within [array.zero]:

6. References