This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 2897. `array::iterator` and `array::const_iterator` should be literal types

Section: 24.3.7.1 [array.overview] Status: Resolved Submitter: Russia Opened: 2017-02-03 Last modified: 2020-09-06

Priority: 2

View other active issues in [array.overview].

View all other issues in [array.overview].

View all issues with Resolved status.

Discussion:

Addresses RU 3

Force the literal type requirement for the `iterator` and `const_iterator` in the `std::array` so that iterators of `std::array` could be used in `constexpr` functions.

Proposed change: Add to the end of the [array.overview] section: `iterator` and `const_iterator` shall be literal types.

[2017-02-20 Marshall adds wording]

I used the formulation "are literal types", rather than "shall be", since that denotes a requirement on the user.

Previous resolution [SUPERSEDED]:

> This wording is relative to N4640.

> 1. Add a new paragraph at the end of 24.3.7.1 [array.overview]:

>    > -?- `iterator` and `const_iterator` are literal types.

[2017-03-01, Kona]

Antony Polukhin provides revised wording.

[2017-03-02, Kona]

Wording tweaks suggested by LWG applied.

[2017-03-02, Tim Song comments]

I don't believe the blanket "all operations" wording is quite correct.

First, `T t;` (required by `DefaultConstructible`) isn't usable in a constant expression if the iterator is a pointer, since it would leave it uninitialized.

Second, an explicit destructor call `u.~T()` (required by `Destructible`) isn't usable if the iterator is a class type because it explicitly invokes a non-`constexpr` function (the destructor); see [expr.const]/2.2.

[2017-03-04, Kona]

Set priority to 2. Lisa and Alisdair to work with Antony to come up with better wording. The same wording can be used for 2938.

Previous resolution [SUPERSEDED]:

> This wording is relative to N4640.

> 1. Add a new paragraph at the end of 24.3.7.1 [array.overview]:

>    > -3- An `array` satisfies all of the requirements of a container […]

>    > -?- All operations on `iterator` and `const_iterator` that are required to satisfy the random access iterator requirements are usable in constant expressions.

[2017-04-22, Antony Polukhin provides improved wording]

[2017-11 Albuquerque Wednesday issue processing]

Status to Open; We don't want to do this yet; gated on Core issue 1581 (affects swap). See also 2800.

Thomas to talk to Anthony about writing a paper detailing what it takes to be a constexpr iterator.

[2017-11 Albuquerque Thursday]

It looks like 1581 is going to be resolved this week, so we should revisit soon.

[2017-11 Albuquerque Saturday issues processing]

P0858R0 (adopted on Sat; to be moved in Jacksonville) will resolve this.

[2018-06 Rapperswil Wednesday issues processing]

This was resolved by P0858, which was adopted in Jacksonville.

Proposed resolution:

This wording is relative to N4659.

1. Add a new paragraph at the end of 25.3.1 [iterator.requirements.general] as indicated:

   > -12- An invalid iterator is an iterator that may be singular.(footnote: […])

   > Iterators are called constexpr iterators if all defined iterator category operations, except a pseudo-destructor call ( [expr.pseudo]) or the construction of an iterator with a singular value, are usable as constant expressions. [Note: For example, the types "pointer to int" and `reverse_iterator<int*>` are constexpr random access iterators. — end note]

   > -13- In the following sections, `a` and `b` denote […]

2. Add a new paragraph at the end of 24.3.7.1 [array.overview]:

   > -3- An `array` satisfies all of the requirements of a container […]

   > -?- `iterator` and `const_iterator` satisfy the constexpr iterator requirements (25.3.1 [iterator.requirements.general]).