On 2012-08-04 21:25, Adam D. Ruppe wrote:
Yes, I agree in general, but if a getter returns a ref, you should
be able to write to it... I think anyway, but it is an lvalue anyway.
Or we could disallow getters returning by reference.
What I just added to my hacked compiler is this:
=====
else if(e1->op == TOKcall) {
// for property work, if there is a setter, we should
revert to the older style
// handling. If not, we can keep it as a CallExp
CallExp* ce = (CallExp*) e1;
Expression* temp_e1 = ce->e1;
if((temp_e1->op == TOKvar &&
temp_e1->type->toBasetype()->ty == Tfunction)) {
// this is potentially a setter.... but not necessarily
fd = ((VarExp *)temp_e1)->var->isFuncDeclaration();
ethis = NULL;
assert(fd);
FuncDeclaration *f = fd;
Expressions a;
a.push(e2);
fd = f->overloadResolve(loc, ethis, &a, 1);
if (fd && fd->type) {
e1 = temp_e1;
goto Lsetter;
}
}
=====
To line 10320 - right above where the old style setter code is. It isn't
perfect yet because it doesn't ensure we are dealing with a @property,
but it is closer.
The idea is: if we have a setter function, we should try to use it, just
like dmd does today. If not, we'll leave the call there and see what
happens. (If it returns ref, it will work, otherwise, it errors saying
the property is not an lvalue.)
So far this is passing my simple test for assignment, but not yet the op
assigns.
int a;
@property int funcprop() {
return a;
}
// setter
@property int funcprop(int s) {
return a = s + 10;
}
funcprop = 10; // works, funcprop == 20 now
Doesn't this already work?
True. I think all the other uses should just work though.
Yes. Have a look at this for a workaround:
http://forum.dlang.org/thread/gknbobkfhmfszshqe...@forum.dlang.org#post-jvjs5j:248ov:241:40digitalmars.com
--
/Jacob Carlborg
