98. Input iterator requirements are badly written

Section: 24.3.5.3 [input.iterators] Status: CD1 Submitter: AFNOR Opened: 1998-10-07 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [input.iterators].

View all other issues in [input.iterators].

View all issues with CD1 status.

Discussion:

Table 72 in 24.3.5.3 [input.iterators] specifies semantics for *r++ of:

   { T tmp = *r; ++r; return tmp; }

There are two problems with this. First, the return type is specified to be "T", as opposed to something like "convertible to T". This is too specific: we want to allow *r++ to return an lvalue.

Second, writing the semantics in terms of code misleadingly suggests that the effects *r++ should precisely replicate the behavior of this code, including side effects. (Does this mean that *r++ should invoke the copy constructor exactly as many times as the sample code above would?) See issue 334 for a similar problem.

Proposed resolution:

In Table 72 in 24.3.5.3 [input.iterators], change the return type for *r++ from T to "convertible to T".

Rationale:

This issue has two parts: the return type, and the number of times the copy constructor is invoked.

The LWG believes the the first part is a real issue. It's inappropriate for the return type to be specified so much more precisely for *r++ than it is for *r. In particular, if r is of (say) type int*, then *r++ isn't int, but int&.

The LWG does not believe that the number of times the copy constructor is invoked is a real issue. This can vary in any case, because of language rules on copy constructor elision. That's too much to read into these semantics clauses.

Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since we're told (24.1/3) that forward iterators satisfy all the requirements of input iterators, we can't impose any requirements in the Input Iterator requirements table that forward iterators don't satisfy.