what to do with postblit on the heap?

[so]

On Tue, 21 Jun 2011 15:25:40 +0300, Michel Fortin  
<michel.fortin at michelf.com> 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!