Using ()s in @property functions

[Robert Jacques]

On Tue, 29 Jun 2010 01:53:05 -0400, Nick Sabalausky <a at a.a> wrote:

> "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.

1. You'd get a closure, not a lambda, which generally would require a heap  
allocation.
2. The idea's not too crazy, I've been having similar thoughts. However,
3. D's a system's programming language and not being able to get a  
function pointer to a function seems wrong.
4. There's actually valid use cases where getting the address of a  
property makes sense. One of the intents of properties is to allow a  
library to upgrade a variable to a set of methods without breaking third  
party user code. And in the new version of your library, taking the  
address might make sense or be needed due to new functionality.

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

It grabs the first overload, IIRC.