On Friday, March 23, 2018 17:20:09 Manu via Digitalmars-d wrote: > On 23 March 2018 at 16:58, Jonathan M Davis via Digitalmars-d > > <[email protected]> wrote: > > On Friday, March 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote: > >> Well, to be honest I still can't understand why would you want to > >> pass a RValue as reference. > > > > Well, it's frequently the case that you don't want to copy an object if > > you don't have to - especially in the gaming world, where every ounce > > of performance matters. If a function accepts an argument by ref, then > > no copy is made, but then you have to pass an lvalue, making it really > > annoying to call the function when what you have is an rvalue. On the > > other hand, if the function doesn't accept its argument by ref, then > > you can pass an rvalue (and it will be moved, making that efficient), > > but then lvalues get copied when that's often not what you want. C++'s > > solution to this was rvalue references. > > Ummm... rvalue-references are something completely different. > rval-ref's are C++'s solution to move semantics. > C++ just simply accepts rvalues passed to const& args. It makes a temp > and passes the ref, as you expect.
It was my understanding that that _was_ an rvalue reference, and I remember that Andrei was against const ref accepting rvalues in D due to issues with rvalue references. It's quite possible that I misremember though, and I certainly am not an expert on all of the issues with rvalues and references in C++, and my C++ knowledge is getting increasingly rusty, since I don't use C++ much anymore. In any case, I have a terrible time remembering Andrei's exact arguments, but he feels very strongly about them, so anyone looking to convince him is going to have a hard time of it. My biggest concern in all of this is that I don't want to see ref start accepting rvalues as has been occasionally discussed. It needs to be clear when a function is accept an argument by ref because it's going to mutate the object and when it's accepting by ref because it wants to avoid a copy. The addition of const solves that problem for C++, but given how restrictive const is in D, I doubt that much of anyone would ultimately be very happy with using const ref in their code very often. > > In many cases, it works great, whereas in others, > > it doesn't work at all (e.g. virtual functions), and it can result in > > template bloat. > > And templates, that's another case where it fails. > auto-ref is something else unrelated to this topic, and it's useful in > a different set of cases for a different set of uses/reasons. It's got > nothing to do with this. auto ref has everything to do with a function accepting both rvalues and lvalues without making a copy. auto ref is the solution that was introduced into D to solve that very problem. It's just that it has limitations that make it inappropriate in a number of cases, so you don't consider it a solution to your problem. > > So, C++ gives you control over which you do, and it's not > > necessarily straightforward as to which you should use (though plenty of > > older C++ programmers likely just use const& all over the place out of > > habit). > > D gives you the same set of options; except that passing args by ref > is a PITA in D, and ruins your code. Which is why I said that D doesn't give you the same set of options. - Jonathan M Davis
