Discussion: Rvalue refs and a Move construtor for D

[Suleyman]

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.