DIP 1016--ref T accepts r-values--Community Review Round 1

[Steven Schveighoffer]

On 7/20/18 3:36 PM, Jonathan M Davis wrote:
> 
> The reality of the matter is that it's always going to be up to the API
> author on some level - e.g. even if the proposed changes were implemented,
> there's still the question of whether a function's parameter should be
> marked with ref or not, and arguably, in general, it really shouldn't be,
> because it destroys the compiler's ability to move. Yes, by either allowing
> ref to accept rvalues or by adding an attribute like @rvalue to make ref
> accept rvalues, it's then up to the caller as to whether they pass an lvalue
> or rvalue, but it's still up to the API designer to decide how values are
> passed, and in some cases, it really does matter whether rvalues are
> accepted or not.

This has been accepted, pretty much always:

struct S
{
     int x;
     void opOpAssign(string op : "+")(int val) { x += val; }
}

struct Y
{
     S s;
     S foo() { return s; }
}

void main()
{
     import std.stdio;
     Y y;
     y.s += 5;
     writeln(y.s.x); // 5
     y.foo += 5;
     writeln(y.foo.x); // still 5
}

Yet, there has been no major catastrophe, no falling of the sky, no 
errors that I can ever think of that weren't caught because it obviously 
didn't do what it was supposed to. Note also, THERE IS NO WAY TO DISABLE 
IT! If you define operators on a type, you can call them on rvalues. Always.

This is one of the 2 reasons I think that this DIP is OK -- experience 
shows us that the allowance of binding `this` to rvalues hasn't caused 
problems.

The other reason is to avoid having to do acrobatics with static if in 
order to properly accept both rvalues and lvalues. Yes, you can use auto 
ref, but there are many cases where it's not desirable to use templates. 
Those are pretty well outlined in the DIP.

-Steve