rvalues -> ref (yup... again!)
Manu
turkeyman at gmail.com
Mon Mar 26 19:26:20 UTC 2018
On 26 March 2018 at 11:13, John Colvin via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote:
>>
>> On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote:
>>>
>>> Forked from the x^^y thread...
>>> <snip>
>>
>>
>> There are too many replies on this thread, addressing all the comments
>> would take forever and pollute the thread itself. So forgive me if I say
>> something that was covered already by someone else.
>>
>> AFAIK being able to bind rvalues to `ref const(T)`, only makes sense when
>> calling C++ functions that take `const T&` (especially since that is
>> common). I have not yet heard any other use for them. I'd be in favour of
>> allowing it _only_ for `extern(C++)` functions. Otherwise use `auto ref` or
>> have overloads for pass-by-value and pass-by-ref.
>> I too, once a recent immigrant from the lands of C++, used to keep writing
>> `ref const(T)`. I just pass by value now.
>>
>> C++ T&& (forwarding reference) -> D auto ref T
>> C++ T&& (Rvalue reference) -> D T
>> C++ const T& -> D T
>> C++ T& -> D ref T
>>
>> If replacing const T& with T chafes, I understand. I used to feel that way
>> too. It's _possible_ that would incur a penalty in copying/moving, but IME
>> the cost is either 0, negligible, or negative (!).
>
>
> I'm tearing my remaining stubs of hair out trying to understand why memory
> copies (not talking about copy constructors) are needed when passing an
> rvalue to a non-ref function:
> https://stackoverflow.com/questions/49474685/passing-rvalue-to-non-ref-parameter-why-cant-the-compiler-elide-the-copy
Passing rvalues to non-ref functions may elide a memory copy. Moves
can be very efficient.
But we're talking about ref functions right? Not not-ref functions...?
More information about the Digitalmars-d
mailing list