On Thursday, 24 January 2013 at 21:44:12 UTC, Adam Wilson wrote:
From the compilers standpoint they are functions. It must be
so. That's how they're implemented.
No, they are @property functions. That's important because it
lets them be rewritten at the usage point, similarly to operator
overloading and various other tricks in the language, which also
doesn't care about function call syntax, despite being
implemented as functions.
I was messing with the compiler a while ago to make my vision
work. Got about 90% there, but it got too messy when doing
setters. Only made 5 changes:
DsymbolExp::semantic
if the function this references was declared as a property,
rewrite the symbol to be a call expression
Thus "bar", if bar was declared as @property, is rewritten into
"(bar())" and the rest carries on normally. (So if the whole
expression was "bar().foo", the rest of the compiler sees it as
"(bar())().foo" and reacts accordingly.)
DotVarExp::semantic
ditto, but for members instead
And the others were trying to make it work for setters in BinExp,
AssignExp, and a filthy hack in CallExp itself to find the setter
given a getter.
The getter change, about 10 lines of code in dmd, was a success.
The setters are where I tripped up and couldn't get it to work
right, but this is probably because I'm not a dmd master, not
because it is impossible.
