moveAt vs opIndex

[Chris Cain]

In your case, I don't think you really need to define a moveAt. 
opIndex is what's required for a Random Access Range and it 
really doesn't make sense to define moveAt for your particular 
problem.

On Friday, 18 May 2012 at 12:21:31 UTC, maarten van damme wrote:
> Whats the difference between destructively reading and 
> returning?

Destructively reading means it can clear out the space that it's 
returning from. It does this by (effectively) setting that 
position to ElementType.init.

Let's assume it did this for ints (but it doesn't): So, if I have 
an array [2,5,3] and I say "moveAt(1)" it would return 5 and the 
array would be [2,0,3].

The reason it doesn't always work that way is because it will 
only "destructively" read when it's a struct who has a destructor 
defined or has a copy constructor defined. It basically bit 
copies an ElementType.init version over the source to prevent 
that destructor or copy constructor from being called and 
(potentially) doing some unintended things ... like double 
freeing memory (if your struct frees memory).

Generally, most moveAt, moveFront, and moveBack implementations 
will end up calling std.algorithm's move function:
http://dlang.org/phobos/std_algorithm.html#move
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm.d#L1325
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm.d#L1417

> And why would I need to define moveFront and front when I 
> already
> defined opIndex?

front is required for your range to be an input range. The 
compiler does not transfer calls from .front to .opIndex(0) 
implicitly (and it might be problematic for some people if it did 
as you don't want everything to be a range).

If you want that behavior, you have to explicitly define it to 
work that way:
ElementType front() @property { return this[0]; }