[boost] Re: [boost.range] RFC on small updates

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-02-03 04:31:40

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