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.
