C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] std::duplicate
From: Michael Daum (mike.daum_at_[hidden])
Date: 2019-10-02 17:29:46


Tony it's a fine line between genius and insanity.

On Wed, Oct 2, 2019 at 5:44 PM Tony V E <tvaneerd_at_[hidden]> wrote:

> 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
>



STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups