std::next is over-constrained
Eric Niebler

Created on 2013-12-24.00:00:00 last changed 83 months ago


Date: 2015-05-22.19:14:31

Proposed resolution:

This wording is relative to N3797.

  1. Change [iterator.synopsis], header <iterator> synopsis, and [iterator.operations] before p.6 as indicated:

    template <class ForwardInputIterator>
      ForwardInputIterator next(ForwardInputIterator x,
        typename std::iterator_traits<ForwardInputIterator>::difference_type n = 1);
Date: 2015-05-22.19:14:31

[ Lenexa 2015-05-07: Move to Ready ]

Date: 2013-12-24.00:00:00

In LWG 1011, std::next and std::prev were changed from accepting InputIterator to accepting ForwardIterator. This needlessly excludes perfectly legitimate use cases. Consider the following hypothetical range-based implementation of drop, which creates a view of a range without the first n elements:

template<typename Distance, typename InputRange>
drop(Distance n, InputRange& rng)
  return make_iterator_range(
    std::next(std::begin(rng), n),

I believe this to be a legitimate use case that is currently outlawed by the standard without cause. See the discussion beginning at c++std-lib-35313 for an in-depth discussion of the issue, in which Howard Hinnant agreed that it was a defect.

(Some discussion then ensued about whether an overload should be added that only accepts rvalue InputIterators to avoid the surprise that issue 1011 sought to address. I make no such attempt, nor do I believe it to be necessary.)

Suggested resolution:

Back out the resolution of 1011.

Date User Action Args
2017-07-30 20:15:43adminsetstatus: wp -> c++17
2015-10-27 16:52:45adminsetstatus: ready -> wp
2015-05-22 19:14:31adminsetmessages: + msg7436
2015-05-22 19:14:31adminsetstatus: new -> ready
2014-01-12 22:13:32adminsetmessages: + msg6791
2013-12-24 00:00:00admincreate