Ranges

[Yigal Chripun]

BLS wrote:
> dsimcha wrote:
> 
>> 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*.
> 
> What I don't get is how this (definition) may work on tree based 
> structures. To me it seems that ranges work fine on "linear" data types 
> (whatever) lists, but well,  as said I don't get it. :(

as I understand this, A range is alway some linear (iteration) order of 
the elements.
so a tree structure can provide:
tree.preOrder()
tree.inOrder()
tree.postOrder()

which return three different ranges representing these orderings of the 
tree elements.

a sub-tree will be of type tree itself and has nothing to do with ranges.

you can of course combine the two, e.g.:
AVLtree.left.right.left.postOrder;

for linear structures. e.g. an array these two operations are the same.
int[100] arr;
auto slice = arr[40, 50];
slice is both a sub-array and a range of that sub-array.