Uniform Function Call Syntax(UFCS) and @property

[Jonathan M Davis]

On Thursday, March 03, 2011 09:14:36 kenji hara wrote:
> Current D's property-like function call is too loose.
> Under current rule, following both two statements being legal.
> void f(int n){...}
> f(10);
> f = 10;
> 
> If @property will separate these two syntax definitely, but UFCS will
> introduce the ambiguity again:
> // future code
> @property void f(int n){}
> f = 10;
> 10.f;
> 
> We also definitely separate 'this' value where UFCS is allowed.

UFCS is supposed to be allowed _everywhere_, or it isn't universal, and if it 
isn't universal, I don't really such much point to it personally.

And I don't see any real ambiguity in those functions even with UFCS. A module 
level function which returns void and takes only one parameter shouldn't be a 
legal property. A property function should be a function which operates _on_ 
something. It's an abstraction for a member variable. So, a getter property on a 
user-defined type should return a value and take nothing and a setter property on 
a user-defined type should return void and take a single parameter. But a getter 
property which isn't a member function should return a value and take a single 
parameter which is the type which the property is on, and a setter property 
which is a setter function should return void and take two parameters - the type 
which the property is on and the value to set.

As such, I see no ambiguity. What you're suggesting complicates things and 
restricts UFCS such that it isn't really all that useful. The whole point of 
UFCS is that it be universal.

- Jonathan M Davis