--- Comment #3 from yebblies <> 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);
// 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:
------- You are receiving this mail because: -------

Reply via email to