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.

### 3601. `common_iterator`'s `postfix-proxy` needs `indirectly_readable`

Section: 25.5.5.5 [common.iter.nav] Status: WP Submitter: Casey Carter Opened: 2021-09-24 Last modified: 2022-02-10

Priority: Not Prioritized

View all other issues in [common.iter.nav].

View all issues with WP status.

Discussion:

It would appear that when P2259R1 added `postfix-proxy` to `common_iterator::operator++(int)` LWG missed a crucial difference between `operator++(int)` and `operator->` which uses a similar proxy: `operator->` requires the wrapped type to be `indirectly_readable`, but `operator++(int)` does not. Consequently, operations that read from the wrapped type for the `postfix-proxy` case in `operator++(int)` are not properly constrained to be valid.

[2021-10-14; Reflector poll]

Set status to Tentatively Ready after six 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 N4892.

1. Modify 25.5.5.5 [common.iter.nav] as indicated:

   >     decltype(auto) operator++(int);

   > > -4- Preconditions: `holds_alternative<I>(v_)` is `true`.

   > > -5- Effects: If `I` models `forward_iterator`, equivalent to:

   > > >     common_iterator tmp = *this;
   > > >     ++*this;
   > > >     return tmp;

   > > Otherwise, if `requires (I& i) { { *i++ } -> can-reference; }` is `true` or `indirectly_readable<I> && constructible_from<iter_value_t<I>, iter_reference_t<I>> && move_constructible<iter_value_t<I>>` is `false`, equivalent to:

   > > >     return get<I>(v_)++;

   > > Otherwise, equivalent to: […]