Using ()s in @property functions

[Robert Jacques]

On Tue, 29 Jun 2010 00:02:32 -0400, Rainer Deyke <rainerd at eldwood.com>  
wrote:
> On 6/28/2010 20:40, dsimcha wrote:
>>  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.
>> }
>
> Allowing parentheses also leads to ambiguity:
>
>   struct Foo {
>       uint num;
>
>       @property int delegate() front() {
>           return delegate (){ return 5; };
>       }
>   }
>
>
>   void main() {
>       Foo foo;
>       auto bar = foo.front();  // What is the type of 'bar'?
>   }
>
> The problem is that 'front' refers to two things: the property and its
> accessor function.  So long as this is the case, ambiguity is  
> unavoidable.
>
>

So... If we allow properties to be called using () syntax, we have corner  
case ambiguities. And if we don't allow properties to be called using ()  
syntax, we have corner case ambiguities and a minor loss of function  
(because one ambiguity can't be expressed). Add in Andrei's posts about  
the difficulty in deciding what methods should and shouldn't be  
properties, and the more it seems that the real world experience with  
properties is indicating that @property is a mis-feature that should be  
dropped from the language.