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

[mist]

On Friday, 25 January 2013 at 15:57:16 UTC, deadalnix wrote:
> No adress because :
>  - it would now be impossible to ensure transition using & as 
> NOOP.
>  - this address is useless anyway. That'd be a pointer to a 
> pointer to instructions.
Need to think about it.

> 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?

> 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[])"

> 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.

> Many people here disagree. I tend to be amongst thoses people. 
> This specific case imply no ambiguity, and is similar to other 
> simplification D already make like . dereferencing pointers.
Well, then it is probably best to focus on free-form property 
semantics and leave argument about optional parens and friends - 
there were enough of them in this topic ;) I'll push for optional 
ones to the end but hope at least for the solution where 
ambiguity is consistently resolved.