DIP 1016--ref T accepts r-values--Formal Assessment

[aliak]

On Thursday, 31 January 2019 at 21:50:32 UTC, Steven 
Schveighoffer wrote:
> On 1/31/19 4:46 PM, Olivier FAURE wrote:
>> On Thursday, 31 January 2019 at 18:31:22 UTC, Steven 
>> Schveighoffer wrote:
>>> BTW, the DIP discusses how to annotate these rare situations:
>>>
>>> int doubleMyValue(ref int x) { ... }
>>> @disable int doubleMyValue(int x);
>>>
>> 
>> I don't think that's a solution. The problem is in the getter 
>> method, not in doubleMyValue. If nothing else, since the DIP 
>> is designed to work on existing functions, it could happen on 
>> doubleMyValue functions which would be both designed by and 
>> used by people completely unaware of DIP-1016.
>
> How is the problem not in doubleMyValue? It's sole purpose is 
> to update an lvalue. It is the perfect candidate to mark with 
> @disable for rvalues.
>
> -Steve

Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a 
getter? For it not to be a compile error pt.x should also have a 
setter, in which case the code needs to be lowered to something 
else:

{
   auto __temp = pt.x;
   doubleMyValue(__temp);
   pt.x = __temp;
}

I believe this is something along the lines of what Swift and C# 
do as well.

Or something... a DIP to fix properties anyone? :)

Also, this applies to a much wider variety of operations on 
properties that return rvalues and not just on functions calls no?

struct B {
     int x;
}
struct A {
   B _b;
   @property B b() { return _b; }
}

void main() {
     A a;
     a.b.x += 1;
     writeln(a.b.x); // 0
}