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.
