Using ()s in @property functions

[Andrei Alexandrescu]

Chad J wrote:
> On 06/30/2010 12:33 AM, Robert Jacques wrote:
>> On Tue, 29 Jun 2010 23:41:48 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>> .
>>> 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
>> I agree with you from a under-the-hood perspective, but I wasn't asking
>> about that. I was asking about the leak in the @property abstraction.
>> Not being able to pass non-ref @properties to functions by ref is a
>> fairly serious (i.e. common) break/leak in the @property abstraction:
>> that @properties should be "virtually indistinguishable from a field".
> 
> ref parameters are easily handled by property expression rewriting:
> 
> void foo( ref bar ) { ... }
> 
> foo(prop)
> 
> becomes
> 
> auto t = prop()
> foo(t)
> prop(t)

I think that would be very error-prone.

Andrei