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.

2242. [uninitialized_]copy_n() defect

Section: 27.7.1 [alg.copy], 27.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: