"Steven Schveighoffer" <schvei...@yahoo.com> wrote in message news:op.vj9cunrweav...@localhost.localdomain... > Someone was asking about UFC syntax for properties on d.learn, and I > realized, we have a huge ambiguity here. > > Given a function: > > @property int foo(int x) > > Is this a global setter or a getter on an int? > > i.e. > > int y = foo = 3; > > or > > int y = (3).foo; > > ??? > > I know arrays have an issue with property setters, see a bug report I > filed a while back: > > http://d.puremagic.com/issues/show_bug.cgi?id=3857 > > But that seems like a totally unambiguous case (a global property function > with two parameters is obviously a setter on the first parameter in UFC). > > The getter seems much more problematic. Does anyone have a solution > besides adding more syntax? Should we disallow global properties to avoid > ambiguity? >
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. Additionally, with that understanding in place, this: @property void foo(int x) {...} (3).foo(); Is probably the one place where UFC syntax should never be allowed, because it's obviously a setter, and since when does this ever make any sence: int x; (3).x; // Set x to 3?? WTF??