ideas about ranges

[dsimcha]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> On Tue, 26 May 2009 13:45:05 -0400, Steve Teale
> <steve.teale at britseyeview.com> wrote:
> > Steve,
> >
> > I'm glad to see that there are others out there who are equally
> > skeptical about ranges..
> >
> > Your point about Ranges being similar to an early view of OOP is a good
> > one. Just because someone comes up with an interesting concept, it does
> > not mean you need to use it all the time, or even ever if it does not
> > sit well with you.
> Ranges to me are a great concept.  They are safer than C++ iterators, but
> they are not exactly new.  For example Java Iterators are essentially
> input ranges.
> However, STL algorithms applied to such concepts has not often been done
> (if ever before), probably because not many languages have such extensive
> template support.  It's certainly an interesting pairing, and I think it
> will prove to be a great fit.
> On the skeptical side, I don't think ranges are a great fit for all cases
> where C++ iterators work well.  Using iterators as a marker, for instance,
> is not handled well by a range.  It seems to me that streams also don't
> fit well as a range (but certainly there needs to be some connector code
> between ranges and streams).
> So I guess, you wouldn't call me a skeptic, but I'm certainly not
> convinced that ranges are the solution to all problems :)
> -Steve

You may be right.  D's ranges may be in some ways slightly less powerful than C++
iterators, for reasons you pointed out, but IMHO they're better even if they are.
 I believe that trying to make something flexible enough to handle 99-100% of use
cases is a recipe for disaster, as whatever you come up with will be way too
complex and difficult to use for the easiest 90-95% of cases.  It's better to make
it handle the easiest 90-95% of cases well, i.e. with as much conceptual
simplicity and consistency and as little boilerplate as possible, and assume that
people will roll their own custom solution for the really hard cases, since they
probably will anyhow.  In other words, worse really is better sometimes.

I've programmed very little in C++, but during my forays into it, I've always felt
that STL iterators were so mind-numbingly verbose and ugly that I really didn't
want to use them no matter how flexible or efficient they were.  They are so messy
that ad-hoc roll-your-own solutions start to seem like a better idea for a lot of
the simpler cases, and this is exactly what I usually did.