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.

3472. counted_iterator is missing preconditions

Section: 25.5.7 [iterators.counted] Status: WP Submitter: Michael Schellenberger Costa Opened: 2020-07-29 Last modified: 2020-11-09

Priority: Not Prioritized

View all issues with WP status.

Discussion:

C++20 introduces a new iterator counted_iterator that keeps track of the end of its range via an additional exposition only member length.

Consequently, there are several preconditions for many member functions of counted_iterator, but it seems some are missing:

1. operator*

   Here we have no precondition regarding length. However, given that length denotes the distance to the end of the range it should be invalid to dereference a counted_iterator with length 0.

   Moreover, operator[] has a precondition of "n < length". Consider the following code snippet:

   int some_ints[] = {0,1,2};
   counted_iterator<int*> i{some_ints, 0};
   

   Here "i[0]" would be invalid due to the precondition "n < length". However, "*i" would be a valid expression. This violates the definition of operator[] which states according to 7.6.1.2 [expr.sub] p1:

   […] The expression E1[E2] is identical (by definition) to *((E1)+(E2)) […]

   Substituting E2->0 we get

   […] The expression E1[0] is identical (by definition) to *(E1) […]

   With the current wording counted_iterator violates that definition and we should add to operator*:

   Preconditions: length > 0.

2. iter_move

   This is a similar case. We have only the Effects element:

   Effects: Equivalent to: return ranges::iter_move(i.current);

   However, looking at the requirements of ranges::iter_move we have in 25.3.3.1 [iterator.cust.move] p2:

   If ranges::iter_move(E) is not equal to *E, the program is ill-formed, no diagnostic required.

   This clearly requires that for counted_iterator::iter_move to be well-formed, we need counted_iterator::operator* to be well formed. Consequently we should also add the same precondition to counted_iterator::iter_move:

   Preconditions: length > 0.

3. iter_swap

   This is essentially the same arguing as for counted_iterator::iter_move. The essential observation is that ranges::iter_swap is defined in terms of ranges::iter_move (see 25.3.3.2 [iterator.cust.swap]) so it must have the same preconditions and we should add:

   Preconditions: length > 0.

[2020-08-21 Issue processing telecon: moved to Tentatively Ready.]

[2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP.]

Proposed resolution:

This wording is relative to N4861.

1. Modify 25.5.7.4 [counted.iter.elem] as indicated:

   constexpr decltype(auto) operator*();
   constexpr decltype(auto) operator*() const
     requires dereferenceable<const I>;
   

   -?- Preconditions: length > 0.

   -1- Effects: Equivalent to: return *current;

2. Modify 25.5.7.7 [counted.iter.cust] as indicated:

   friend constexpr iter_rvalue_reference_t<I>
     iter_move(const counted_iterator& i)
       noexcept(noexcept(ranges::iter_move(i.current)))
       requires input_iterator<I>;
   

   -?- Preconditions: i.length > 0.

   -1- Effects: Equivalent to: return ranges::iter_move(i.current);

   template<indirectly_swappable<I> I2>
     friend constexpr void
       iter_swap(const counted_iterator& x, const counted_iterator<I2>& y)
         noexcept(noexcept(ranges::iter_swap(x.current, y.current)));
   

   -?- Preconditions: x.length > 0 and y.length > 0.

   -1- Effects: Equivalent to: return ranges::iter_swap(x.current, y.current);