== Quote from Steve Teale ([email protected])'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.
