Using ()s in @property functions

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Jun 29 08:44:07 PDT 2010


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


More information about the Digitalmars-d mailing list