Using ()s in @property functions

[Chad J]

On 06/28/2010 10:40 PM, dsimcha 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?  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?


I don't think it should be possible to take the address of a property.
I also think applying @property to normal fields would have special
behavior.  The effect would be a field that can't be addressed.  Ideally
this would be the default, to make it more intuitive to build flexible
APIs, but I think we are too late for that bit of niceness.  Just having
that ability to build flexible APIs at all (in this case) by using
@property fields would be a good start.

I wouldn't mind having some way to grab the delegate, but I think it
should be very explicit.  "This may break your code if the library
writer changes their implementation" kinda explicit.