On Mon, 19 Sep 2011 11:17:01 -0400, Kagamin <s...@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
