On 26 March 2018 at 11:13, John Colvin via Digitalmars-d <[email protected]> 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...?
