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 = ∝
>>> >
>>> >>(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