"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m1lla6dm6b.fsf@tulip.office.meta... | Thorsten Ottosen writes: | > | > 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, | > 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? well, no, but std::string is extreame. | > 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 *). in some sence operator*() is provided by operator[]()... I guess random access iterators will fit must use cases like strings. But OTOH, I don't see how two functions (let's scrap advance) can hurt at all, not even in a standardization context. -Thorsten