what to do with postblit on the heap?

[Jonathan M Davis]

On 2011-06-20 18:59, Michel Fortin wrote:
> On 2011-06-20 18:12:11 -0400, "Steven Schveighoffer"
> 
> <schveiguy at yahoo.com> said:
> > On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin
> > 
> > <michel.fortin at michelf.com> wrote:
> >> My feeling is that array appending and array assignment should be
> >> considered a compiler issue first and foremost. The compiler needs to
> >> be  fixed, and once that's done the runtime will need to be updated
> >> anyway  to match the changes in the compiler. Your proposed fix for
> >> array  assignment is a good start for when the compiler will provide
> >> the  necessary info to the runtime, but applying it at this time will
> >> just  fix some cases by breaking a few others: net improvement zero.
> > 
> > BTW, I now feel that your request to make a distinction between move
> > and  copy is not required.  The compiler currently calls the destructor
> > of  temporaries, so it should also call postblit.  I don't think it can
> > make  the distinction between array appending and simply calling some
> > other  function.
> 
> Well, if
> 
> 	a ~= S();
> 
> does result in a temporary which get copied and then destroyed, why
> have move semantics at all? Move semantics are not just an
> optimization, they actually change the semantics. If you have a struct
> with a @disabled postblit, should it still be appendable?

I would expect that to have move semantics. There's no need to create and 
destroy a temporary. It's completely wasteful. A copy should only be happening 
when a copy _needs_ to happen. It doesn't need to happen here. Now, depending 
on what ~= did internally (assuming that it were an overloaded operator), then 
a copy may end up occurring inside of the function, but that shouldn't happen 
for the built-in ~= operator, and a well-written overloaded ~= should avoid 
the need to copy as well.

- Jonathan M Davis