Hi,
That's what I've been trying to explain here. I concede with limited success. The documentation suggests that a SinglePassRange is sort of a "pair of interators". But it turns out that any Container is also a SinglePassRange.
As it can be interpreted as a pair of iterators...why not? It would be confusing if standard containers would not model a SinglePassRange. Ignore for a moment the write up in the documentation. And instead think about the sentence "Every squence that can be represented by an iterator to the beginning and the end, is a SinglePassRange". This already encompasses standard containers and many things more. Now looking back at the documentation it is about how boost range formalises this concept in it's most abstract form. This is the reason why the following:
Nomenclature
R SinglePassRange type r instance of a type R
valid expressions
r.begin() r.end()
is not a correct description of the abstraction, as the library is in fact more genral. So this description would be truely misleading as it would encourage the thinking of a SPR as something having methods begin() and end(). In fact the biggest achievement of boost range is that it strays from this path saying that it is boost::begin(r) and boost::end(r). It is a different way of thinking about the ranges. You are thinking about "how can i see that my class conforms to the range concept" and the document is about "what is a range?"
To be conforming, something like "struct iterator_range" would have to supply the same functions. The notion boost::begin(r) and boost::end(r) seems out of place to me. I haven't thought through all the implications of this as it would have rippled through the library design. So cut me some slack here.
person who came up the with the name "concept" for what to me would better be called "type requirement".) This is your biggest misunderstanding is that you think about the range concept as type requirements even though th concept of a range is meant as a concept of a range.