moveAt vs opIndex

[Jonathan M Davis]

On Friday, May 18, 2012 14:21:23 maarten van damme wrote:
> I am trying to write a randomaccessinfinite range that returns primes
> using the sieve of aristotle. I am however having problems
> understanding the difference between moveAt and opIndex;
> 
> according to dlang;
> ElementType opIndex(size_t n);
> Returns the nth element in the composite range. Defined if all ranges
> offer random access.
> 
> ElementType moveAt(size_t n);
> Destructively reads the nth element in the composite range. Defined if
> all ranges offer random access.
> 
> Whats the difference between destructively reading and returning?
> 
> And why would I need to define moveFront and front when I already
> defined opIndex?

The fact that you define opIndex has no effect on front. It's not like front is 
going to be magically defined just because you defined opIndex. The same goes 
with any other range function. If you don't define that specific function, then 
it's not there. Functions are never generated just because you happen to have 
one which could be used to implement another one. For a range to be a random 
access range, it must implement all of the primitives of a bidirectional range 
in addition to opIndex, which means front, back, popFront, popBack, and save. 
If any of those aren't implemented, then your type isn't a random access 
range.

moveFront is used to move the front of a range for stuff like swap, when simply 
copying elements is too expensive. It's "destructive" in that the element 
isn't there anymore when you do that. I'm not quite sure what really uses it 
other than swap though. moveAt is the same except that it's for the given 
index instead of front.

There was some talk of getting rid of the moveX primitives and just assuming 
that structs are cheap to copy, but I don't know quite where that stands. But 
AFAIK, the only reason to implement the moveX primitives (per 
std.range.hasMobileElements) is if you're concerned about having elements 
which are structs which have posblits which aren't O(1). If you're generating 
primes, that shouldn't be an issue at all.

- Jonathan M Davis