On 2011-06-20 18:59, Michel Fortin wrote: > On 2011-06-20 18:12:11 -0400, "Steven Schveighoffer" > > <[email protected]> said: > > On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin > > > > <[email protected]> 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
