common_iterator's postfix-proxy is not quite right
Tim Song

Created on 2021-04-23.00:00:00 last changed yesterday


Date: 2021-05-10.16:28:00

Proposed resolution:

This wording is relative to N4885.

  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 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:

    postfix-proxy p(**this);
    return p;

    where postfix-proxy is the exposition-only class:

    class postfix-proxy {
      iter_value_t<I> keep_;
      postfix-proxy(iter_reference_t<I>&& x)
        : keep_(std::moveforward<iter_reference_t<I>>(x)) {}
      const iter_value_t<I>& operator*() const {
        return keep_;
Date: 2021-05-15.00:00:00

[ 2021-05-10; Reflector poll ]

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

Date: 2021-04-26.18:06:21

P2259R1 modeled common_iterator::operator++(int)'s postfix-proxy class on the existing proxy class used by common_iterator::operator->, but in doing so it overlooked two differences:

  • operator->'s proxy is only used when iter_reference_t<I> is not a reference type; this is not the case for postfix-proxy;

  • operator-> returns a prvalue proxy, while operator++'s postfix-proxy is returned by (elidable) move, so the latter needs to require iter_value_t<I> to be move_constructible.

The proposed wording has been implemented and tested.

Date User Action Args
2021-05-10 16:28:00adminsetmessages: + msg11796
2021-05-10 16:28:00adminsetstatus: new -> ready
2021-04-24 17:14:28adminsetmessages: + msg11786
2021-04-23 00:00:00admincreate