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

### 3660. `iterator_traits<common_iterator>::pointer` should conform to §[iterator.traits]

Section: 25.5.5.2 [common.iter.types] Status: WP Submitter: Casey Carter Opened: 2022-01-20 Last modified: 2022-02-10

Priority: Not Prioritized

View all issues with WP status.

Discussion:

25.3.2.3 [iterator.traits]/1 says:

> […] In addition, the types

> >     iterator_traits<I>::pointer
> >     iterator_traits<I>::reference

> shall be defined as the iterator's pointer and reference types; that is, for an iterator object `a` of class type, the same type as `decltype(a.operator->())` and `decltype(*a)`, respectively. The type `iterator_traits<I>::pointer` shall be `void` for an iterator of class type `I` that does not support `operator->`. […]

25.5.5.2 [common.iter.types]/1 slightly contradicts this:

> The nested typedef-names of the specialization of `iterator_traits` for `common_iterator<I, S>` are defined as follows.

> 1. […]

> 2. (1.3) — If the expression `a.operator->()` is well-formed, where `a` is an lvalue of type `const common_iterator<I, S>`, then `pointer` denotes the type of that expression. Otherwise, `pointer` denotes `void`.

"The type of `a.operator->()`" is not necessarily the same as `decltype(a.operator->())`: when the expression is an lvalue or xvalue of type `T`, "the type of `a.operator->()`" is `T` but `decltype(a.operator->())` is either `T&` or `T&&`. An implementation therefore cannot conform to the requirements of both cited paragraphs for some specializations of `common_iterator`.

The most likely explanation for this contradiction is that the writer of the phrase "type of `a.operator->()`" was not cognizant of the difference in meaning and intended to actually write `decltype(a.operator->())`.

[2022-01-30; Reflector poll]

Set status to Tentatively Ready after five votes in favour during reflector poll.

[2022-02-10 Approved at February 2022 virtual plenary. Status changed: Tentatively Ready → WP.]

Proposed resolution:

This wording is relative to N4901.

> [Drafting Note: The wording change below includes an additional drive-by fix that ensures that the last sentence "Otherwise, `pointer` denotes `void`" cannot be misinterpreted (due to the leading "If") to apply also for a situation when the outcome of the expression `a.operator->()` for a non-`const` `common_iterator<I, S>` is reflected upon.]

1. Modify 25.5.5.2 [common.iter.types] as indicated:

   > -1- The nested typedef-names of the specialization of `iterator_traits` for `common_iterator<I, S>` are defined as follows.

   > 1. […]

   > 2. (1.3) — Let `a` denote an lvalue of type `const common_iterator<I, S>`. If the expression `a.operator->()` is well-formed, where `a` is an lvalue of type `const common_iterator<I, S>`, then `pointer` denotes `decltype(a.operator->())`the type of that expression. Otherwise, `pointer` denotes `void`.