Using ()s in @property functions

[Andrei Alexandrescu]

Robert Jacques wrote:
> 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?

I don't think you should be able to even take the address of a non-ref 
property.

Andrei