This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 2931. Missed optimization opportunity with single-argument `std::next`

Section: 25.4.3 [iterator.operations] Status: Open Submitter: Morwenn Opened: 2017-02-04 Last modified: 2018-12-03

Priority: 3

View other active issues in [iterator.operations].

View all other issues in [iterator.operations].

View all issues with Open status.

Discussion:

It seems that `std::next` is missing an optimization opportunity when taking a single parameter. The standard mandates that `std::next` shall call `std::advance` on the passed iterator and return it. For random-access iterators, it means that `operator+=` will be called on the iterator. However, if a single-argument overload was added to `std::next`, it could call `++it` directly instead of `std::advance(it, 1)`, which means that `operator++` would be called instead of `operator+=`. This might make a small performance difference for complicated iterators such as `std::deque`'s ones, where `operator++` has a simpler logic than `operator+=`.

An equivalent optimization could be allowed by adding a single-argument overload to `std::prev` too.

[2017-03-04, Kona]

Set priority to 3. Alisdair to provide wording.

[2018-11-30, Jonathan comments, recommending NAD]

Jonathan suggested NAD, because the proposed "just use increment when `n==1`" optimization can be done in `std::next` (and/or `std::advance`, and/or complicated iterators like `deque::iterator`) without adding an overload. Billy said the overload would avoid metaprogramming costs for dispatching to the right `std::advance`, and help in non-optimized builds. Zhihao said the overload would make it clear to users that the `n==1` case is optimized (Jonathan thinks this is irrelevant as there's no requirement that we tell users what we optimize).

Proposed resolution: