Similar to https://issues.dlang.org/show_bug.cgi?id=12683
Long story short:
//----
void redirect(T)(T t)
{
bar(t); //Postblit here
}
void bar(T)(T t);
//----
Again, while I don't think we can elide the copy entirelly, I think we *can* elide the postblit entirely.
Again, the reasons for allowing this are the same as 12683: There are *tons* "redirect" functions that do nothing more than wrap a call to another functions. The call to postblit is wasteful, and prevents usage with unique objects.
Furthermore, this would be necessary for a more efficient "forward" template. Currently, forward calls "T move(ref T t)". The "move" template in algorithm is actually incredibly wasteful for types with postblits: It creates a 2 temporaries, it calls 2 memcopies, and it calls a destructor (on an object with T.init state). *ALL* of this is exceedingly wasteful, for what should be essentially be a no-op function...
Having this is necessary for fixing:
https://issues.dlang.org/show_bug.cgi?id=12628
emplace does not work for rvalues
Comment #1 by razvan.nitu1305 — 2022-08-22T15:42:43Z
I don't this is possible. Think about reference counting. Maybe T is a reference counted object. Once you call bar you need to update the number of references that point to the object (you don't know what bar is going to do, maybe it will escape the object in some variable), so you cannot avoid calling the posblit/copy constructor.
I think that the correct way to go about this is to properly implement move constructors and devise a last use dataflow analysis strategy that will allow us to properly implement perfect forwarding.
I suggest closing this as invalid.