Thorsten Ottosen writes:
| > value_type& at( size_type ) const; | | Is it a checked version of 'operator[]'?
yes.
I'm against it, then. If you want range checking for debugging purposes, all major standard library implementations offer a debug mode that is much better and consistent at that. If you want it to throw in release and yet don't want the rest of the checks offered by the debug mode, I'd like to see your use case.
| > 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,
True. But they actually _are_ often-used and are actually a part of the "standard" range interface; in contrast, in four years of our own 'iterator_range's life, we didn't need 'narrow' functionality often enough to factor it out into an utility function, let alone making it the class' member. FWIW.
but the idea was that these two helper functions should be made just a little more convenient.
I understand that, but then consider that there are may be ten more such convenience functions lurking out there. We certainly don't want 'iterator_range' to become another 'std::string', do we? Also consider that many of these utility functions are in fact applicable not only to iterator ranges, but to ranges in general. While we don't have a generic range library in Boost yet, it certainly wouldn't hurt to keep in mind a bigger picture.
So you don't think the iterator capabilities is worth the trouble?
They are just one possible workaround for the lack of 'foreach', hardly commonplace and arguably unidiomatic, and as such are at best of a subjective utility. Something like that might be offered by some other library that targets to compensate this language shortcoming, but they certainly don't belong to 'iterator_range'. Straightforward and uncontroversial is IMO what we should target for here.
| 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?
I meant iteration shortcuts (advance, ++ and *). I have no experience with subranges, and therefore have no opinion on that part of your post. -- Aleksey Gurtovoy MetaCommunications Engineering