This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
[uninitialized_]copy_n() defectSection: 26.7.1 [alg.copy], 26.11.5 [uninitialized.copy] Status: NAD Submitter: Sean Parent Opened: 2013-02-14 Last modified: 2017-06-05
Priority: 2
View other active issues in [alg.copy].
View all other issues in [alg.copy].
View all issues with NAD status.
Discussion:
copy_n() and uninitialized_copy_n() only return the output iterator, and not the input iterator.
Likely the interface was simply copied from the original STL. Unfortunately the interface in the original STL contains a bug.
copy_n() and uninitialized_copy_n() must return the resulting input iterator as well as the output
iterator (I would suggest returning a pair). Without this, there is no way to continue reading from an actual input
iterator — and if it is really a forward iterator, it will cost n increments to get back to where you were.
[2016-08 Chicago]
Tues PM: refer to LEWG
[2017-02 in Kona, LEWG recommends NAD]
Potentially breaks lots of things. Cannot overload on return type. Pair, tuple, or struct return? New name? Needs paper with a new algorithm (copy_n_works)? Not an issue for istream iterators (can get stream and get a new iterator). Don’t use this function, use ranges.
[2017-06-02 Issues Telecon]
This change has been made in the Ranges TS.
Resolve as NAD
Proposed resolution: