Using ()s in @property functions

[Nick Sabalausky]

"Robert Jacques" <sandford at jhu.edu> wrote in message 
news:op.ve1p6xrt26stm6 at sandford.myhome.westell.com...
> 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.

Hell no. It's far better than what we had before, and far better than just 
simply not having properties. I wouldn't mind improvements, but as for 
ditching it: there's a baby in that bathwater.