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: 23.3.3.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 23.3.3.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(i).

Previous resolution [SUPERSEDED]:

This wording is relative to N4640.

  1. Add a new paragraph at the end of 23.3.3.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(i).

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 24.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 23.3.3.1 [array.overview]:

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

    -?- iterator and const_iterator satisfy the constexpr iterator requirements (24.3.1 [iterator.requirements.general]).