Yes the name is tricky.  I couldn't find anything better than duplicate, and someone suggested to me that perhaps the forwarding of passed rvalue params could be considered an "implementation detail", and that the function should be called duplicate, that's what it does.  Whatever the name ends up being, it should work well with std::move in my opinion because I think that in the future they could be taught together as sides of the coin.

Yes pending the feedback I get from this list I would definitely like to write a proposal for this!

On Wed, Oct 2, 2019 at 2:02 PM Gašper Ažman <> wrote:
Fair enough :).

Seems like a plausible proposal. The name is bikesheddable, because it's not quite the same as auto{value}, which I would consider to be "duplicate" - it always creates a new object, unlike the proposed std::duplicate.

Are you intending to write the proposal?

On Wed, Oct 2, 2019 at 6:59 PM Michael Daum <> wrote:
Pass by value could be argued to be the current best practice, but:
- It can be slightly sub-optimal by one move to the best practice I am proposing.
- Rather than provide the caller with a clear choice on lvalue parameters, it will silently copy in if the lvalue parameter is not moved
- Value parameters in the signature of the function provided no indication that they are intended to be sunk
Which is why I think all around I have come around to liking && for sink params.

On Wed, Oct 2, 2019 at 1:46 PM Gašper Ažman <> wrote:
Not to bash on your proposal - but why should sink parameters not be by-value? Duplicate is default, move an optimization.

There is also auto{v} which gives you a copy if lvalue, or a moved-to if rvalue.


On Wed, Oct 2, 2019, 17:03 Michael Daum via Std-Proposals <> wrote:
I've become quite fond of a utility called `CopyTemp` which exists in the Unreal Engine code base.  So much so that I think that it should be standardized.  For lack of a better name, I'll call it `std::duplicate`.

Like std::move, std::duplicate would take an argument of any value category and provide a return which is an rvalue.  However, std::duplicate would accomplish this by copying when it had to. Sample Implementation

Once we have this utility, we are able to say that the best practice for providing a sink parameter is to declare it with rvalue reference type.  Attempts to call the sink with lvalue arguments will cause a compiler error forcing to caller to either `std::move` or `std::duplicate` the arg when passed into the call.  Compilers would be able to provide very clean, readable errors if they wanted to, and the resulting code would be optimal in terms of number of copies and moves.

The strengths of this proposal are:
- It is library only
- It is tiny, self contained, and easy to implement
- Helps solve a problem for which we have no great best practice (sink parameters) in a teachable, optimal way which actually makes the calling code more safe and readable
Std-Proposals mailing list