On Wednesday, 10 February 2016 at 20:42:29 UTC, w0rp wrote:
The only remaining time you need to avoid copies is when you
take something already on the stack, and then put it into some
other object, into some collection, etc. That's the other power
that std::move affords you. The move functions in std.algorithm
should take care of that.
Maybe someone else will correct me on a point or two there, but
that's the understanding of move semantics in D that I have had.
Maybe this is what you are referring to, but the primary use I
get out of move semantics (in general, not language-specific) has
little to do with performance-on-copy. It is for handling
resources which logically aren't copyable, which have a unique
owner at all times and which should be cleaned up as soon as
unique owner falls out of scope. This situation occurs a lot for
me, and RAII plus move semantics are pretty close to ideal for
handling it. Yes, it can be approximated with reference counting,
but reference counting has its own downsides.
C++11 definitely supports this use case. I -think- that D does as
well, possible compiler issues aside, though I haven't used it as
extensively here to be sure yet. It does seem as though one has
to be more careful using these semantics in D, because of how
easy it is to stuff such an object into a GC-based container and
thereby lose the deterministic nature of the cleanup, but that's
just more something to be aware of than a true limitation.
