I presume you mean
rng::copy( istream_range<char>( is ), ... );
yup
?
| >at leastv some people wanted that idiom to work.
I don't know how to settle this. I remember at least Alisdair wanted direct iterator support.
So instead of intrinsic support for iterators in collection-traits we would make a range class for each such iterator-type. The benefit would be, you would argue, that we needed that range class anyway. Some would say they don't need a range class at all, so its just extra work.
As far as my implementation would be concerned, it would simplify things a great deal. I would have to write code to recognize each type of iterator because a std::iterator<...> partial template speciaization will not pick up iterators derived from std::iterator<...>.
Anyway, if yours and Matthew's range lib will provide range_adapters that makes it super easy to define
In general you need to create a wrapper, which is not very hard. I could have a range_adapter which will work exactly for this type of iterators.
[remark: I see two distinct libs emerging in your work: (1) range-stuff (2) range algorithms]
;)
| >| Since we have value_of, iterator_of, etc., why not reference_of, | >| const_reference_of? | > | >As I write in the faq, reference_of<T>::type can just be value_type_of<T>::type &. | > | > | > | As I remember, that's not necessary true for new iterator types...
True. I don't think it is holds for existing iterators. But it must be convertible value_type. Hence const reference_type_of<T>::type& can be used to bind a temporary. I just don't see how coding with reference_type_of<T>::type in an algorithm will buy you anything. I might be wrong.
I haven't thought that far. I guess if someone will need, will just tell you in the future. So, lets wait and see ;) Best, John -- John Torjo Freelancer -- john@torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!