http://d.puremagic.com/issues/show_bug.cgi?id=8371



--- Comment #4 from Christophe Travert <christophe.trav...@normalesup.org> 
2012-07-11 00:47:45 PDT ---
> It can't be random access without being bidirectional

Shame...

> and it can't be bidirectional without having a start/end index.

I was about to mention that, in fact, it can have a slice operator and only one
start index, which moves the elements while copying them. In the same way, the
range can be bidirectional and have only one start index if it moves its
elements while poping back. I think such range with a small capacity should
have this behavior. No need to use 2 indices to build a 2-element range, and I
don't even talk about 0- and 1-element range. By the way, no need to copy the
whole data when slicing. Only the sliced part should be copied. The same is
valid for save.

It should be noted that such range with a large capacity does not fullfill the
complexity requirements: copy, save and opSlice are O(n). When opSlice is O(n),
in principle, it should not be provided. Algorithms would better not see an
O(n) opSlice, and use normal iteration instead. An opSlice returning a cheap
dynamic array may be proposed, but it can be dangerous, since the it will not
own its data.

In any case, the implementation should be tuned for small range, and the
documentation should explicitely mention the limits of this range with a large
capacity.

Finally, convenience function to build a range with a capacity that is larger
than the initial number of elements should be provided. For example:

// r can be initialized with 1 or 2 elements, but is the same type in both
cases
auto r = test? range(1, 2): range!2(1);


side note: 
While writing this example, I wanted to write "auto range = ...". But it is not
possible if the new range is called 'range'... In some place, the code of
std.range uses the token range (I found one in walklength). That would break if
the new range is called range. In many many places, the documentation of
std.range (and std.algorithm, and probably many other), use the word "range".
That would not block the compilation, but that would break the documentation in
many places. I think the new range should not be called range. I would propose
rangeOf. Or smallRange, to insist on the fact that the range is tuned for a
small capacity.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to