Ok, makes sense now :)
2012/10/31 monarch_dodra <monarchdo...@gmail.com>:
> On Wednesday, 31 October 2012 at 12:46:12 UTC, maarten van damme wrote:
>>
>> In my current code I'd like to do something ala:
>>
>> void main(){
>> getsettest test=new getsettest();
>>
>> test.value+=1;
>> }
>>
>> class getsettest{
>> int myvalue;
>>
>> this(){
>> }
>>
>> @property{
>>
>> int value(){
>> return myvalue;
>> }
>>
>> void value(int value){
>> myvalue=value;
>> }
>> }
>> }
>>
>> but this gives the following error:
>> test.d(4): Error: test.value() is not an lvalue
>>
>> Is there a rationale behind this decision of not translating
>> test.value+=1 to test.value= test.value +1 ?
>
>
> It's not that simple as "test.value" is not an LValue, so from the
> compiler's perspective "test.value = test.value + 1" calls two different
> functions, that may or may not have anything to do with each other.
>
> The expansion "++ => +=1 => a = a + 1" works if there is only 1 lvalue the
> whole chain through.
>
> Can the compiler really assume it can do that? And is it a smart move to
> allow it to make that assumption. What you have there is basically an
> encapsulated field, that does not leak its address:
>
> You can take the filed, you can update it with a new value, but you can't
> modify it.
>
> If you allow "test.value+=1", then where does it end?
>
> Is this legal?
> //----
> void foo(int& a) {...}
> foo(test.value);
> //----
>
> Would you want the compiler to expand it into:
> //----
> void foo(int& a) {...}
>
> //scope for __temp
> {
> auto __temp = test.value;
> foo(temp);
> test.value = temp;
> }
> //----
>
> --------------------
> IMO, if you take the time to write both functions, instead of just:
> //----
> @property ref int front(){return myvalue;}
> //----
> Then the compiler must assume you did it for a reason, and not mess with
> your code.
