"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m1fz0ff8q8.fsf@tulip.office.meta... | Thorsten Ottosen writes: | > I have planned to add a few extra convenience function to | > iterator_range and sub_range. Some people have said the classes | > could have been a little easier to use. The changes I suggest are the | > following: | > | > iterator_range: | > -------------- | > | > value_type& front() const; | > value_type& back() const; | > value_type& operator[]( size_type ) const; | | Assuming that 'operator[]' is provided only for Random Access | iterators, the above three are very reasonable. yes, only when the underlying range has randomaccessiterators. | > value_type& at( size_type ) const; | | Is it a checked version of 'operator[]'? yes. | > void advance( size_type ); | > void narrow( size_type left, size_type right ); | > iterator_range& operator++(); | > value_type& operator*() const; | | Please NO. 'narrow' can be a freestanding utility function, front() and back() are also easy to make freestanding, but the idea was that these two helper functions should be made just a little more convenient. So you don't think the iterator capabilities is worth the trouble? | and the | rest is at best a questionable "convenience" baggage with no value for | generic code. Also, think "standardization". Do you mean make_sub_range() and the others? br -Thorsten