Using ()s in @property functions

[Steven Schveighoffer]

On Tue, 29 Jun 2010 11:44:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 29 Jun 2010 10:15:10 -0400, Leandro Lucarella  
>> <luca at llucax.com.ar> wrote:
>>
>>> Steven Schveighoffer, el 29 de junio a las 08:13 me escribiste:
>>>> >>There is one thing that bugs me about this solution though.  What  
>>>> if the
>>>> >>user does this:
>>>> >>(1) Grab the pointer.  *ptr = prop;
>>>> >(1) Grab the pointer.  T* ptr = &prop;
>>>> >
>>>> >>(2) assigns to it.  *ptr = val;
>>>> >>(3) expects the result to be updated in prop.  assert(val == prop);
>>>> >
>>>>
>>>> Why would this assert fail?  If a property returns a ref
>>>
>>> What if it doesn't? If returns a temporary calculated value?
>>  It returns a ref.  That can't be a calculated value.  If it's a  
>> calculated value then T* ptr = &prop will fail to compile.
>
> It's a "calculated reference", e.g. several instances could share the  
> same value etc. Once the reference is out, clearly there's no more  
> control.

Yes, my point was simply, for anything that returns ref:

auto ptr = &foo();
*ptr = x;

is equivalent to
foo() = x;

>
> I agree with the view that a @property returning ref should be virtually  
> indistinguishable from a field. Currently that's not the case, e.g. if  
> you want to assign to such a property you must add parens:
>
> struct A { int x; @property ref y() { return x; } }
>
> unittest
> {
>      A a;
>      a.y = 5; // fails
>      a.y() = 5; // works
> }

http://d.puremagic.com/issues/show_bug.cgi?id=3511

-Steve