Reduced test case:
//----
auto pipe(T)(T t)
{
return t; //HERE
}
//----
It is my understanding that the compiler can't elide the copy entirely, since the location of the argument and the location of the return value are not the same.
However, I think the compiler should be able to elide the call to the postblit entirelly: It should simply move the bits in "t" to its final destination, and avoid calling the dtor on the original object.
Rationale:
1. Performance:
- There are *tons* of functions that return its args. "D" makes it legal to move things around, so we should exploit it.
- More performance. There are "even more" tons of if trivial "helper" functions, such as "binaryFun"/"lambda" that would benefit from this.
2. It's the next logical step for factory/"named constructor" idiom. For example:
S s = makeS()
.setVal(5)
.setArg(2);
Currently, in the above code, if "S" has a postblit, then it will be called on those two extra function calls.
Furthermore, this improvement is necessary to allow support for "unique objects" that have disabled postblit. Currently, code that takes an argument, mutates it, then returns it, can't operate on unique types, even if the original object is an RValue.
Comment #1 by robert.schadek — 2024-12-13T18:20:19Z