Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Sat, Sep 7, 2019 at 5:50 PM Suleyman via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 7 September 2019 at 21:41:16 UTC, kinke wrote:
> > We have ref, auto ref, scope ref, return ref, now we're
> > discussing @rvalue ref...
>
> At this point we should consider having an rvalue pointer type.
> We have concluded that preserving the rvalueness of a ref (which
> is simply a pointer) is valuable, we could take it further and
> save the rvalueness in pointer types as well. I find it strange
> that you cant declare a pointer to an rvalue ref in C++ for
> example `int&&*`.

I think the reason is that, in C++, pointers would be eliminated from
the language if they could get away with the deviation from legacy.
In C++, ref's are part of the type, and this works immeasurably better
than this 'storage class' idea we have in D. So when they added rval
ref's, they extended the expression for pointers that they would
prefer you invest in, which is references in general.

I think the advantage of using references for rvalues, is that you
can't assign references, you can't store them off somewhere, which is
the implication that you take from being handed a pointer.
If we introduce rval pointers, then you'd be able to assign them, make
struct members, all that stuff, which you can't do with ref's.

I find it a bit weird to think about an rvalue pointer, because the
natural conclusion is that I can create one on the stack and freely
assign to/from it, or as a member of a struct... that gets strange
very quickly.