Uniform Function Call syntax for properties

[Denis Koroskin]

On Sat, 09 Oct 2010 23:37:51 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/9/10 13:33 CDT, Steven Schveighoffer wrote:
>> On Fri, 08 Oct 2010 16:56:14 -0400, Nick Sabalausky <a at a.a> wrote:
>>
>>>
>>> Ugh, it seems D still doesn't quite understand the concept of a  
>>> property.
>>> Here:
>>>
>>> @property int foo() // Obviously getter
>>> @property void foo(int x) // Obviously setter
>>>
>>> No other form makes any sence as a property. Frankly, I'm very  
>>> surprised,
>>> and dissapointed, that anything else is even allowed. The only  
>>> *possible*
>>> exception being:
>>>
>>> @property int foo(int x) // Combined getter/setter, if we decide that's
>>> needed
>>>
>>> It doesn't make any sense for a property getter to have a parameter
>>> (unless
>>> it's one parameter and it's used to set a new value). And it doesn't  
>>> make
>>> any sence for a setter to have anthing other than exactly one  
>>> parameter.
>>> Just disallow it. What could possibly be the point anyway? If it's got
>>> parameters it's a function call, not a variable.
>>
>> Property setters can have two parameters, one is the item used to set
>> it, and one is the rvalue to use when setting. In objects, the first
>> parameter is the hidden this parameter. With UFC, the parameter is
>> explicit. Unless you feel builtin arrays should never have properties?
>>
>> The only exception are global properties which are not set on anything.
>> And this is the problem.
>>
>> I think the syntax discussed in the other part of this thread is
>> probably a good way to disambiguate the issues.
>>
>> -Steve
>
> One possibility is to simply say that
>
> @property int foo(T x);
>
> always means a getter for T. This is because if you want to define a  
> global with getter and setter you can always write a type with  
> assignment and alias this.
>
>
> Andrei

I respectfully disagree. I strongly believe writing getters and setters  
should be a) consistent with each other and b) consistent with  
class/struct properties.