Using ()s in @property functions

[Chad J]

On 06/29/2010 11:38 AM, 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.
> 
>>
>>> then you
>>> set through that ref.  What you did is no different, you just
>>> delayed the assignment for a bit.
>>>
>>> You can reduce your test case to:
>>>
>>> (1) assign to the property.   prop = val;
>>
>> Is not the same at all! prop = val will call the setter function, *ptr
>> = val will not!
> 
> Maybe you are thinking of something different, here is the code we're
> discussing:
> 
> struct Foo {
>     uint num;
> 
>     @property ref uint front() {
>         return num;
>     }
> }
> 
> -Steve

Ah, so we're speaking only of ref-returning properties.  It took me this
post and some of its replies until I realized this restriction.  Sorry,
I was speaking about properties in general.

Actually this is really cool.  I hadn't thought of ref-returns as a way
to escape the lack-of-addressability problem.  I'm too sleepy to think
of the consequences of this, but so far I like it!