common_iterator's postfix-proxy needs indirectly_readable
Casey Carter

Created on 2021-09-24.00:00:00 last changed 1 month ago


Date: 2021-10-14.11:35:22

Proposed resolution:

This wording is relative to N4892.

  1. Modify [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;
    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: […]

Date: 2021-10-15.00:00:00

[ 2021-10-14; Reflector poll ]

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

Date: 2021-09-24.00:00:00

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.

Date User Action Args
2021-10-14 11:35:22adminsetmessages: + msg12148
2021-10-14 11:35:22adminsetstatus: new -> ready
2021-09-24 17:06:49adminsetmessages: + msg12070
2021-09-24 00:00:00admincreate