rvalues -> ref (yup... again!)

[Jonathan M Davis]

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
>
> <digitalmars-d at puremagic.com> 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