Using ()s in @property functions

[Steven Schveighoffer]

On Tue, 29 Jun 2010 08:05:04 -0400, Chad J  
<chadjoan at __spam.is.bad__gmail.com> wrote:

> Whoops, made a mistake.
>
> On 06/29/2010 08:03 AM, Chad J wrote:
>> On 06/29/2010 07:16 AM, Steven Schveighoffer wrote:
>>> If I'm reading this correctly, you are saying that you want &foo.front
>>> to return a pointer to uint, not a delegate?
>>>
>>> This is what I'd expect if @property forced no parentheses.  That is,
>>> foo.front can be replaced with (foo.front()) always, so &foo.front
>>> always translates to &(foo.front()).
>>>
>>> What this means is that you can't get a delegate to the property
>>> function.  This makes sense -- if you replaced the property with an
>>> actual field, you wouldn't be able to get a delegate anyways.  A
>>> property should operate just like a field.
>>>
>>> -Steve
>>
>> That's the spirit of it.  Properties are fields, except much more
>> powerful but addressing is tricky.
>>
>> 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, 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;
(2) expects the result to be updated in prop.  assert(val == prop);

-Steve