Is regular overwrite copy mode undefined for Container iterators? - c++

Question

The following code compiles just fine, overwriting the values in v2 with those from v1:
std::vector<int> v1 = {1, 2, 3, 4, 5};
std::vector<int> v2 = {6, 7, 8, 9, 10};
std::copy(v1.begin(), v1.end(), v2.begin());
The third argument of std::copy is an OutputIterator. However, the Container requirements specify that a.begin(), where a is a Container object, should have a return type of iterator which is defined as:
any iterator category that meets the forward iterator requirements.
Forward iterator requirements do not include the requirements of output iterators, so is the example above undefined? I'm using the iterator as an output iterator even though there's no obvious guarantee that it will be one.
I'm fairly certain the above code is valid, however, so my guess is that you can infer from the details about containers that the forward iterator returned by begin() will in fact also support the output iterator requirements. In that case, when does begin() not return an output iterator? Only when the container is const or are there other situations?

Answer 1

Forward iterators can conform the the specifications of an output iterator if they're mutable, depending on the type of the sequence. It's not explicitly spelled out (unlike the fact that they to input iterator requirements), but if we take a look at the requirements table
we can go and check if a given forward iterator conforms to them:
*r = o
(§24.2.5/1): if X is a mutable iterator, reference is a reference to T
A mutable reference is assignable (unless you have a non-assignable type, obviously).
++r, r++, *r++ = o
(§24.2.5 Table 109)
The first line in Table 109 is the same requirement as for output iterators, except that forward iterators don't have the remark. The second line is more restrictive than for output iterators, since it specifies that a reference must be returned.
Bottom line, if you have a mutable forward iterator into a sequence of copy-assignable types, you have a valid output iterator.
(Technically, a constant iterator into a sequence of types that have a operator=(...) const and mutable members would also qualify, but let's hope nobody does something like that.)

Answer 2

Forward iterator requirements do not include the requirements of output iterators
This sounds backwards. OutputIterators need to satisfy fewer criteria than ForwardIterators.
(Forward iterators should be reusable after increment, i.e. incrementing them twice should yield the same result).
Therefore, it is ok provided that the output iterator stays valid until the algorithm completes. IOW:
auto outit = std::begin(v2);
std::advance(outit, v1.size()); // or: std::distance(std::begin(v1), std::end(v2))
// outit should still be valid here
Edit To the comment:
§ 24.2.1
Iterators that further satisfy the requirements of output iterators are called mutable iterators. Nonmutable iterators are referred to as constant iterators.
Now, let me find the bit that ties this together saying vector::begin() returns mutable Random Access iterator.
For info
§ 24.2.5 Forward iterators [forward.iterators]
1 A class or pointer type X satisfies the requirements of a forward iterator if
X satisfies the requirements of an input iterator (24.2.3),
X satisfies the DefaultConstructible requirements (17.6.3.1),
if X is a mutable iterator, reference is a reference to T; if X is a const iterator, reference is a reference to const T,
the expressions in Table 109 are valid and have the indicated semantics, and
objects of type X offer the multi-pass guarantee, described below.