On 02/22/2012 03:16 PM, Blake Anderton wrote:
> With an array the above tests work (I assume because each
> operation is implicitly a new slice?).
It works because the slice itself is copied to count() and count()
consumes that copy internally.
Now I see the issue here: Why does 'alias this' disable the parameter
copying behavior? Why is the member slice not being copied?
This must be clarified. Is this a bug? A hole in the spec?
> I found I can fix the above example by aliasing a function that returns
> a slice of the member array instead of aliasing the field itself,
That function is called save() on ForwardRange ranges and does exactly that.
> but
> that may still be too close a relationship of the container/range. My
> instinct (which could be completely wrong) is that it's fine since the
> container is taking responsibility for creating valid ranges, it is just
> doing so implicitly.
>
> User code having to explicitly take ranges (either through opSlice or a
> property/method) isn't a terrible thing, but it would be convenient to
> not have to take that extra step.
You have to decide whether this is a container or a range. If it's a
range, the users should be able to freely consume it from the top and
save copies of it by save() when they need to. I recommend defining the
range functions directly on this type in that case.
Ali
