Using ()s in @property functions

[Robert Jacques]

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.
>
> 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
> }
>
>
> Andrei

Okay, but what about non-ref properties? i.e.

struct A {
    int x;
    @property int y()      { return x; }
    @property int y(int v) { return x = v; }
}

unittest {
    A a;
    int* ptr = &a.x; // works
    int* ptr = &a.y; // fails
}

Is there a good way of patching this leak in the @property abstraction?