Discussion: Rvalue refs and a Move construtor for D

[kinke]

On Thursday, 5 September 2019 at 22:28:44 UTC, Manu wrote:
> On Thu, Sep 5, 2019 at 2:55 PM kinke via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Thursday, 5 September 2019 at 21:31:59 UTC, Manu wrote:
>> > We lose by-val calling semantics, which are more efficient 
>> > for
>> > small
>> > struct's (most things), and certain classes of 
>> > wide-registers in
>> > various architectures (impossible to codify the proper rules 
>> > in
>> > the
>> > language).
>>
>> No, I've explicitly stated that this obviously only affects 
>> non-PODs and large PODs. On Win64, `large` is already anything
>> > 8 bytes. Of course we don't want to pass an int by ref.
>
> You dismissed the second half of my sentence.

Didn't seem relevant, as these are all ABI details, and I am 
aware of this. My generalization wrt. > 8 bytes on Win64 wasn't 
totally accurate; vectors > 8 bytes are indeed passed in a vector 
register. [I have implemented this for LDC - still not fully 100% 
__vectorcall compatible.]

> We have `auto ref`, and I expect that would express that case 
> in a more clear way.

Yes, definitely better. Brings me to this further refinement of 
my sketch, staying with Suleyman's recursive function:

void foo()(auto ref S value, int n = 0)
{
     if (n > 32)
         return;

     // forwarding `auto ref` params in the value case could be 
optimized to
     // 'just forward the [rvalue] ref, don't destruct and reset 
to T.init afterwards'
     foo(forward(value), n + 1); // still calls the value version 
of foo
}

void main()
{
     S lvalue;
     foo(move(lvalue)); // pass rvalue directly by ref, then 
destruct and reset to S.init
}

=> 2 destructions, 1 reset to S.init.