On 10/9/10 13:33 CDT, Steven Schveighoffer wrote:
On Fri, 08 Oct 2010 16:56:14 -0400, Nick Sabalausky <a...@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
