Re: range processing extensions

From: James Mitchell (jimdesu_at_[hidden])
Date: 2001-12-23 18:54:30

> For what it's worth, I still think incrementors and decrementors are
> beneficial.  (I'd prefer names like pop_front() and pop_back() to operator
> overloading. We ought to support bi-directional ranges as well as forward
So far as operator overloading goes for a range, I think it's important to
overload at least the increment and decrement operators because they provide
pre- and post- semantics.  I dislike the pop_front() and pop_back() because
that becomes too container-like for my tastes.  It also implies that you can
shorten a range but not extend it, although that might be a matter of
interpretation.  I definitely want to support both recursive and procedural
styles, and pop_front() & pop_back() raise the question: "are the
prior(last) elements still in the range?".  With operator++() and
operator--()(& their "int" buddies) and pointer-style dereference it's
blatantly obvious that you're operating via indirection to some container
somewhere, rather than dealing with stored values which may or may not
become removed.  The copy vs. reference semantics here are of paramount
importance.  I also think the pointer-like semantics make more sense with
generators and filters: by keeping with such, you could potentially pass
back to the user a functor of type range<char> returning {'a',...,'z'} or
somesuch, which would work automagically with the operators, but not with
other functions.  (Of course, operator*() would break, but in that case you
should know better than to use it!)  It's more compatible with the
generalized notion of a range not being a collection of indirected things,
per se, but a sequence of values(which may or may not be references to
things).  Granted that I've only skimmed the articles to which you and Darin
have pointed me(xmas things getting in the way of coding-related stuff!), so
this may have been all hashed out already.

James