@property - take it behind the woodshed and shoot it?

[deadalnix]

On Friday, 25 January 2013 at 16:11:53 UTC, mist wrote:
>> funName is not a getter and don't return a delegate. How a 
>> getter behave is explained below. Mixing everything together 
>> is the perfect way to create a mess.
> Well, but it is were good design vs mess of special cases 
> really shines :) Anyway, in this statement by "function" you 
> mean "non-property function", ye?
>

That is one case where it matters.

>> You didn't addressed why @property. Answer you gave to point 5 
>> and 6 make me think you aren't aware of the ambiguities 
>> @property causes with UFCS. Please note that :
>> [1, 2].front and front = [1, 2] are semantically 100% 
>> equivalent.
> Not really as I see it.
> [1, 2].front // requires signature "@property T front(int[])"
> front = [1, 2] // compile error
> arr.front = [1, 2] // requires signature "@property void 
> front(T, int[])"
>

So you DO make a difference between setters and getters.

>> The above code is rewritten ad funName()(t) .
> Ah, _now_ I am starting to get your proposal. And do not like 
> it in that regard.
>

funName(t) is valid if funName returns a delegate. The compiler 
shouldn't even try to interpret funName(...) as a call of funName.