I have been using the highly concise and intuitive C++ syntax for finding the intersection of two sorted `vector`

s and putting the result in a third `vector`

:

```
vector<bar> a,b,c;
//...
std::set_intersection(a.begin(),a.end(),b.begin(),b.end(),
std::back_inserter(c));
```

This should set `c`

to intersection(`a`

,`b`

), assuming `a`

and `b`

are sorted.

But what if I just use `c.begin()`

(I thought I saw an example somewhere of this, which is why I did):

```
std::set_intersection(a.begin(),a.end(),b.begin(),b.end(),
c.begin());
```

`set_intersection`

expects an `OutputIterator`

at that parameter. The standard I believe requires only that `c.begin()`

return a `forward iterator`

, which I suppose might or might not be an `OutputIterator`

.

Anyway, the code with `c.begin()`

compiled under clang.

What is guaranteed to happen under the standard? If this compiles, what is likely to happen - that is, when the iterator returned by `c.begin()`

is eventually incremented past the end of the vector, and an attempt is made to access the element pointed to, what must/may happen? Can a conforming implementation silently extend the vector in this case, so that `begin()`

is in fact an appending `OutputIterator`

like `back_inserter`

is?

I'm asking this mainly to understand how the standard works with iterators: what's really going on, so I can move beyond copy-and-paste in using the STL.