On Saturday, March 24, 2012 23:07:01 Stewart Gordon wrote: > Something else I'm finding puzzling is moveFront, moveAt and moveBack. Is > D trying to be C++11 or something? Move semantics don't seem to me to be > useful in a language with GC.
The GC doesn't have anything do with it. If you're dealing with objects on the GC heap, then they're either references or pointers and the situation is exactly the same as it is in C++ when using pointers except that the memory is freed by the GC when it's not used anymore rather than having to be manually freed. A move constructor doesn't do anything with a pointer in C++. It's when you have objects on the stack that hold stuff (including pointers) where they matter. And since D has structs, a lot of stuff doesn't go on the heap anyway. It sits on the stack just like many C++ objects do. D deals with move semantics better than C++ does (see http://stackoverflow.com/questions/4200190/does-d- have-something-akin-to-c0xs-move-semantics and http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move- semantics for more details), but if you allow arbitrarily complex postblit constructors, then there are some cases where you need to be able to specify that you're moving an object rather than copying it, and that's what the moveX functions are for. They allow a range to explicitly move a value rather than copy it. Now, the moveX functions are probably going to go away at some point, because there's been a fair bit of discussion on assuming that postlbit constructors in D are O(1), which makes it so that you don't have to worry about moves. But they're there because of the possibility of arbitrarily complex postblit constructors. - Jonathan M Davis
