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