On Tue, 21 Jun 2011 15:25:40 +0300, Michel Fortin
<[email protected]> wrote:
Actually, this should be the equivalent:
import std.algorithm;
S tmp;
arr ~= move(tmp);
While there is no doubt that 'moving' a struct can often be used as an
optimization without changing the semantics, if you want the @disabled
attribute to be useful on the postblit constructor then the language
needs to define when its semantics require 'moving' data and whey then
require 'copying' data, it can't let that only to the choice of the
optimizer.
Things might be clearer if we had a move operator, but instead we have a
'move' function. There is only one case where I think we can assume to
have move semantics: when a temporary (a rvalue) is assigned to
somewhere. That's also all that's needed for the 'move' function to
work. And that is broken currently when it comes to array appending.
It should be something else because move(tmp) in std.algorithm takes by
reference and returns by value by actually moving it, because of the value
semantics in D, that the ability to differentiate value from reference it
doesn't need any other syntax because this is much better.
I think it is pretty neat, yet i still have some trouble understanding its
effect here.
S tmp;
arr ~= move(tmp); // would make an unnecessary copy.
Move should do some kind of a magic there and treat its argument like a
value, and return it.
Something like:
move(ref T a)
return cast(T)a;
Maybe it makes no sense at all but i tried!
