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.
Kenji
2011/3/4 Jonathan M Davis <jmdavisp...@gmx.com>:
> On Thursday 03 March 2011 01:52:09 kenji hara wrote:
>> The two semantics have no relation with each other.
>>
>> My idea is that we allow 'this' keyword as the first parameter of free
>> function: ----
>> T t;
>>
>> void method(T)(ref T this){...}
>> --> t.method();
>> void method(T, A...)(ref T this, A args){...}
>> --> t.method(arg1, arg2);
>>
>> @property bool empty(T)(ref T this){...}
>> --> if (t.empty){...}
>> @property void empty(T)(ref T this, bool f){...}
>> --> t.empty = true;
>> ----
>>
>> Do you think?
>
> Why use this like that? UFCS is supposed to work with any function just like
> using the member function call syntax works with arrays and any function -
> otherwise it's not universal. And I would expect @property to work without
> "this". The functions you list should work just fine with arrays without the
> use
> of the keyword "this" and without the first parameter being a ref. The same
> should be true for UFCS if it's ever implemented.
>
> - Jonathan M Davis
>
