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

[aliak via Digitalmars-d-announce]

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
}