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.

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

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 ;/

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

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