Uniform Function Call syntax for properties

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Oct 9 12:37:51 PDT 2010


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


More information about the Digitalmars-d mailing list