Discussion: Rvalue refs and a Move construtor for D

[Manu]

On Sat, Sep 7, 2019 at 6:35 PM Suleyman via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 8 September 2019 at 01:04:35 UTC, Manu wrote:
> > 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.
>
> There is pointer to pointer but there is no ref to ref. That is
> an unjustified limitation. Just because certain aspects of
> pointers can be replaced by doesn't mean ref is good and pointer
> is bad.
>
> > 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.
>
> I'm not sure what you mean. You certainly can store rvalue ref in
> C++ everywhere, even inside structs. And when you take a pointer
> it's just the same underground except that you lose type
> information unjustifiably.
>
> > 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.
>
> You can already do all of that in C++
> https://cpp.godbolt.org/z/ZfdOeu
>
> > 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.
>
> Ref in C++ is unjustifiably limited. And saving rvalueness has
> nothing to do in the ref vs pointer battle.

I understand where you're coming from, but this opens up an enormous
can of worms and widens the scope of the conversation enormously... I
think we have about a 15% chance of being successful with an @rvalue
ref proposal as is, and I feel like if we try and expand that to a
type-constructor and make it applicable to pointers, we fall to around
0.01% change of success.

I spend too much time and energy here as it is. I would advise against
doing something that cuts your chances of success by 1000x, and I
couldn't personally make the time to argue in favour :/