Using ()s in @property functions

[Steven Schveighoffer]

On Mon, 28 Jun 2010 22:40:06 -0400, dsimcha <dsimcha at yahoo.com> wrote:

> Once enforcement of @property is enabled, we need to decide whether  
> calling an
> @property function using ()s should be legal.  In other words, should
> @property **require** omission of ()s or just allow it?

Require it.  Otherwise, we are left with the same situation as before.  We  
already had optional parentheses for properties, and it was/is an  
ambiguity disaster.  It's the whole reason for introducing @property in  
the first place.

>  My vote is for just
> allowing omission, because I've run into the following ambiguity while
> debugging std.range.  Here's a reduced test case:
>
> struct Foo {
>     uint num;
>
>     @property ref uint front() {
>         return num;
>     }
> }
>
> void main() {
>     Foo foo;
>     uint* bar = &foo.front;  // Tries to return a delegate.
> }
>
> If I can assume that @property functions can be called with explicit ()s  
> to
> forcibly disambiguate this situation, then I can fix these kinds of bugs  
> by
> simply doing a:
>
> uint* bar = &(foo.front());
>
> Can we finalize the idea that this will continue to be allowed now so  
> that I
> can fix the relevant bugs in Phobos and know that my fix won't be broken  
> in a
> few compiler releases?

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