Using ()s in @property functions

[Nick Sabalausky]

"dsimcha" <dsimcha at yahoo.com> wrote in message 
news:i0bme6$2phb$1 at digitalmars.com...
> 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?

Crazy idea:

The whole point of properties is to simulate a member that's *not* a 
function. With that in mind, does it even make sense to allow the use of 
unary "&" to get a delegate to a property at all? On the off-chance that you 
really do need a delegate to a setter/getter you can just make a lambda - 
and that works exactly the same even if it's a real member variable instead 
of a property. And inlining could take care of any performance issues.

Somewhat related question: What normally happens when you try to get a 
delegate to an overloaded function?