common_iterator
's postfix-proxy
is not quite rightSection: 24.5.5.5 [common.iter.nav] Status: C++23 Submitter: Tim Song Opened: 2021-04-23 Last modified: 2023-11-22
Priority: Not Prioritized
View all other issues in [common.iter.nav].
View all issues with C++23 status.
Discussion:
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.
[2021-05-10; Reflector poll]
Set status to Tentatively Ready after five votes in favour during reflector poll.
[2021-05-17; Reflector poll]
Set status to Tentatively Ready after five votes in favour during reflector poll.
[2021-06-07 Approved at June 2021 virtual plenary. Status changed: Voting → WP.]
Proposed resolution:
This wording is relative to N4885.
Modify 24.5.5.5 [common.iter.nav] as indicated:
decltype(auto) operator++(int);-4- Preconditions:
-5- Effects: Ifholds_alternative<I>(v_)
istrue
.I
modelsforward_iterator
, equivalent to:common_iterator tmp = *this; ++*this; return tmp;Otherwise, if
requires (I& i) { { *i++ } -> can-reference; }
istrue
orconstructible_from<iter_value_t<I>, iter_reference_t<I>> && move_constructible<iter_value_t<I>>
isfalse
, equivalent to:return get<I>(v_)++;Otherwise, equivalent to:
postfix-proxy p(**this); ++*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)) {} public: const iter_value_t<I>& operator*() const { return keep_; } };