Well, since std::move
- doesn't move
- is an overloaded function name (ie std::move(begin, end, out))

We could call it std::copy

:-)


On Wed, Oct 2, 2019 at 2:06 PM Michael Daum via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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 <gasper.azman_at_[hidden]>
> 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 <mike.daum_at_[hidden]>
>> 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 <gasper.azman_at_[hidden]>
>>> 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.
>>>>
>>>> G
>>>>
>>>> On Wed, Oct 2, 2019, 17:03 Michael Daum via Std-Proposals <
>>>> std-proposals_at_[hidden]> 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
>>>>> <https://godbolt.org/z/7nIJNT>
>>>>>
>>>>> 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.
>>>>> Example <https://godbolt.org/z/Q_E_J->
>>>>>
>>>>> 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
>>>>> Std-Proposals_at_[hidden]
>>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>>
>>>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Be seeing you,
Tony