Ranges

[BLS]

Yigal Chripun wrote:
> 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.

Thanks, Yes that makes sense.