Date: Wed, 2 Oct 2019 14:06:05 -0400
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
>>>>
>>>
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
>>>>
>>>
Received on 2019-10-02 13:08:27