Go and generic programming on reddit, also touches on D

[Steven Schveighoffer]

On Mon, 19 Sep 2011 11:17:01 -0400, Kagamin <spam at here.lot> wrote:

> Steven Schveighoffer Wrote:
>
>> auto set = new TreeSet!uint(1, 3, 5, 7, 9);
>> assert(set.length == 5);
>> auto range = set[1..set.length];
>>
>> assert(walkLength(range) == 2); // probably not what you expected
>
> Where you got that "1"?

1 is the first element in the set.

> How to slice it from begin to 7?

set[set.begin .. 7]

This does not include the element at position 7.  To get that element too,  
you have to do something funky:

auto cur = set.elemAt(7);
cur.popFront();

set[set.begin .. cur];

I haven't thought of an easy way to signify find me the element After X.

> Looks like an operator overload abuse. Slicing is an array's feature. If  
> a collection doesn't support array interface, it's questionable whether  
> it should support slicing as it's defined in D. By stretching slicing to  
> non-array collections you break its semantics. Good for voodoo, bad for  
> engineering.

I emphatically disagree.  Slicing is the method of extracting a range from  
a collection given two reference points.  For arrays, that happens to be  
indexes.  For node-based containers, it would be references to those nodes  
(in dcollections, those are called cursors).  I don't see why slicing  
should be restricted to ints, otherwise, why have opSlice compile with  
anything other than ints?

-Steve