Uniform Function Call syntax for properties

[Jonathan M Davis]

On Friday, October 08, 2010 13:56:14 Nick Sabalausky wrote:
> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
> news:op.vj9cunrweav7ka at 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.

I agree 100%.

> 
> 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??

If literals are considered const or immutable, then this takes care of itself, 
since then the type system would then disallow it.

- Jonathan M Davis