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: […]