On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Daniel Walker skrev:
On 10/29/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
shunsuke skrev:
Thorsten Ottosen wrote:
You would rather see range_mutable_iterator and range_const_iterator there? Yes.
I've found an interesting quote in doc/boost_range.html:
The special metafunctions range_result_iterator and range_reverse_result_iterator are not part of any Range concept,
You knew it. Well, those docs are so old now, I'm not sure they should be take too seriously.
The formulation I'm leaning towards in the new docs are the following:
Single Pass Range:
types:
range_iterator<T>::type range_iterator<const T>::type
What if you have a non-const range of const_iterators? It seems like you still need range_const_iterator.
Why?
I was thinking of a scenario where mutability and constness don't correlate - for example, when an immutable range is not const. However, after taking a second glance at the old docs, I'm not sure this applies to ranges. The return type of begin(r) has always been tied to the constness of r, which is confusing for a non-const immutable range. So, you're suggesting to stop using types to distinguish the mutability of ranges? I think I get it, yeah, that could clean things up. So, if the range is made up of const_iterators, range_iterator<T>::type is const_iterator, and if the range is made up of mutable iterators, range_iterator<T>::type is iterator. begin(r) always returns range_iterator<T>::type: range_const_iterator<T>::type is no longer needed. It does simplify matters. Daniel