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