Ranges

[dsimcha]

== Quote from Steve Teale (steve.teale at britseyeview.com)'s article
> I shall start this again from scratch. Please excuse me for being thick about
it. I have tried before in more direct questions to Andrei, but in the end all I
got was a snotty email telling me not to be a nuisance and RTFD. Unfortunately,
the relevant documentation seems to have disappeared.
> In range.d, in the context of isInputRange, it says:
> "Returns $(D true) if $(D R) is an input range. An input range must
> define the primitives $(D empty), $(D popFront), and $(D front). The
> following code should compile for any input range ..."
> template isInputRange(R)
> {
>     enum bool isInputRange = is(typeof(
>     {
>         R r;             // can define a range object
>         if (r.empty) {}  // can test for empty
>         r.popFront;          // can invoke next
>         auto h = r.front; // can get the front of the range
>     }()));
> }
> I can not possibly be the only D enthusiast who finds this completely
incomprehensible. What is a range? Is it a template interface, or is it just a
trick of template syntax that supports the old assertion that "nobody really
understands templates".
> If ranges are to be a feature of the D language, then they should probably be
supported at language level rather than by some trick that has been discovered by
experimenting with how far you can push templates.
> Also, it would be very useful to have some indication of what you might use them
for. I occasionally had to resort to STL iterators because I wanted to use 'map'.
I agree that the syntax sucked, but nobody is telling me how ranges help.
> I realize that some people with an IQ of 580 will find my questions naive and
misguided - not to mention impertinent, but it seems to me that one of the
responsibilities of being a leader is to explain to less gifted followers what the
fuck is going on. Or maybe I've got it wrong - if you're that bright (sorry Walter
- not you) then perhaps it's just a big ego trip.

Ranges are just pretty much an implicit compile-time interface.  As Ary put it,
compile time duck typing is a pretty accurate description.  Basically, a range
doesn't have to *be* a specific *type*, it just has to support certain specific
*operations*, namely front, popFront, and empty.  As long as it *has* these
operations, and they compile and return what they're supposed to (ElementType!(T)
for front(), void for popFront() and bool for empty), it doesn't matter what type
it *is*.

I guess the best way to think of it is that ranges are simply a convention used in
Phobos about how to define iteration over user-defined types.  If you stick to
this convention, then all the range templates people write implicitly know what to
do with your type even if they know nothing about the specifics of it.

Ranges are really just a form of iterators that's given sane syntax (unlike C++)
and relies on this compile-time duck typing instead of virtual functions and
class-based interfaces (unlike Java and C#).  However, in terms of use cases, they
are the same except that ranges can be used where both efficiency and readability
count.  (C++ neglects readability, Java/C# neglect efficiency.) Really, they are
nothing more than a way of encapsulating (at compile time, but not necessarily at
runtime) iteration over user-defined types so that generic code can be written to
work on these types.

I suspect that your lack of understanding of ranges stems from lack of
understanding of templates, since you mention that "noone understands templates"
and once you get templates, ranges are ridiculously simple.  If that's the case,
then your best bet is probably to learn a little more about templates (which are
so fundamental to what makes D special IMHO that I would say that, for all
practical purposes, if you don't understand templates you don't understand D) and
then try to understand ranges again.