Date: Wed, 2 Oct 2019 13:59:14 -0400
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
>>
>
- 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:01:37