www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Getter an lvalue and cannot be modified

reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
C[] c;
 property C[] get() { return c; }

get ~= something;

errors out, yet

auto q = get;
q ~= something;

is fine.


Why is D thinking that ~= is being applied to get, the function, 
rather than what it returns?

Also

When I converted a field in to a property, an AA, it is returning 
null rather than being initialized by default. Seems like 
properties are broke. I'd expect a property getter to behave, for 
all intents and purposes as if it were field. I shouldn't have to 
have a temp variable to be able to use it as such.
May 27 2018
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions 
wrote:

 C[] c;
  property C[] get() { return c; }

 get ~= something;

 errors out, yet

 auto q = get;
 q ~= something;

 is fine.


 Why is D thinking that ~= is being applied to get, the 
 function, rather than what it returns?

 Also

 When I converted a field in to a property, an AA, it is 
 returning null rather than being initialized by default. Seems 
 like properties are broke. I'd expect a property getter to 
 behave, for all intents and purposes as if it were field. I 
 shouldn't have to have a temp variable to be able to use it as 
 such.


You'll probably get your answer and more by reading this:  
https://github.com/dlang/DIPs/pull/97

TL;DR:  return `ref C[]`

Mike
May 27 2018
parent reply IntegratedDimensions <IntegratedDimensions gmail.com> writes:
On Sunday, 27 May 2018 at 09:28:36 UTC, Mike Franklin wrote:

 On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions 
 wrote:

 C[] c;
  property C[] get() { return c; }

 get ~= something;

 errors out, yet

 auto q = get;
 q ~= something;

 is fine.


 Why is D thinking that ~= is being applied to get, the 
 function, rather than what it returns?

 Also

 When I converted a field in to a property, an AA, it is 
 returning null rather than being initialized by default. Seems 
 like properties are broke. I'd expect a property getter to 
 behave, for all intents and purposes as if it were field. I 
 shouldn't have to have a temp variable to be able to use it as 
 such.


 You'll probably get your answer and more by reading this:  
 https://github.com/dlang/DIPs/pull/97


I came across a few posts mentioning this after the fact. It's 
been this way since at least 2012 so... It's now may so not sure 
how much longer we'll have to wait. That pull seems to have 
stalled. So close but so far away ;/
May 27 2018
parent Mike Franklin <slavo5150 yahoo.com> writes:
On Sunday, 27 May 2018 at 23:21:05 UTC, IntegratedDimensions 
wrote:


 I came across a few posts mentioning this after the fact. It's 
 been this way since at least 2012 so... It's now may so not 
 sure how much longer we'll have to wait. That pull seems to 
 have stalled. So close but so far away ;/


It's currently on me to finish the DIP, but I'd rather find a way 
to implement this in the library, so we can deprecate  property 
altogether favoring fewer, more powerful language features.  The 
more I think about it though, that's probably not feasible.

Anyway, after I finish the DIP it will have to go through the 
review process, and given the current rate of review, that's 
going to take a very long time, unfortunately.

Mike
May 27 2018
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 5/27/18 5:23 AM, IntegratedDimensions wrote:

 C[] c;
  property C[] get() { return c; }
 
 get ~= something;
 
 errors out, yet
 
 auto q = get;
 q ~= something;
 
 is fine.


It's "fine", but not doing what you may expect.

This appends an element to q, but does nothing to c.

While an array is not exactly a value type, it's also not exactly a 
reference type. This is why the compiler complains -- your original code 
will append an element and then throw that addition away.


 Why is D thinking that ~= is being applied to get, the function, rather 
 than what it returns?


When I try this, it says "get() is not an lvalue and cannot be 
modified", which seems to indicate that the expression get() (meaning 
what it returns) is not an lvalue. While it's a bit ambiguous in this 
case, a more complicated expression would be self-explanatory. Maybe the 
error message could be prepended with 'the expression' to make it clearer.


 When I converted a field in to a property, an AA, it is returning null 
 rather than being initialized by default.


AAs are initialized as null, not sure what you are expecting here? An 
example may clear things up.


 Seems like properties are 
 broke. I'd expect a property getter to behave, for all intents and 
 purposes as if it were field. I shouldn't have to have a temp variable 
 to be able to use it as such.


You don't normally, but if you want to treat it as an lvalue, 
unfortunately, you do.

The workaround is to spell things out:

prop = prop + 1; // instead of prop += 1

But this doesn't work in all cases.

-Steve
May 29 2018