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



--- Comment #3 from yebblies <yebbl...@gmail.com> 2012-07-11 16:40:19 EST ---
(In reply to comment #1)
> I think it should have assignable elements. It is trivial to support.

It doesn't make much sense if it's a value type.

auto r = range(3, 2, 1);
sort(r);
// r is still 3, 2, 1

If you really want to use it like a static array you could just access the
content directly.  I dunno, being a value type makes this a weird thing.


(In reply to comment #2)
> I'm not sure how should support slicing. The most economic way to implement
> this range is to use a static array and an index indicated the next value.
> Slicing this range would require either:
>  - to store an extra index in the range... that would be sad IMHO, because it
> is often not needed.
>  - to return something else than a "range":
>    - a struct containing the static array and the slice. That seems to be
> overkill.
>    - a dynamic array. Then the slice would not be a value type like the range
> is.
> 
> The dynamic array option is the most reasonable to me.

It can't be random access without being bidirectional, and it can't be
bidirectional without having a start/end index.

struct Range(T, size_t N)
{
   T[N] data;
   size_t first, last;
   void popFront() { first++; }
   void popBack() { last--; }
   @property T front() { return data[first]; }
   @property T back() { return data[last-1]; }
   @property bool empty() { return first >= last; }
   auto opIndex(size_t i) { return data[first+i]; }
   auto save() { return this; }
   auto opSlice() { return this; }
   auto opSlice(size_t lo, size_t hi) { return typeof(this)(data, first+lo,
first+hi); }
}

So if it's random access, it can support slicing.

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

Reply via email to