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
