Re: Getter an lvalue and cannot be modified
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
Re: Getter an lvalue and cannot be modified
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
Re: Getter an lvalue and cannot be modified
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 ;/
Re: Getter an lvalue and cannot be modified
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
