Bug 124 – Enhancement: Operator overloading without temporaries

digitalmars.com digitalmars.D:35949 Since the above proposal received a positive response from Walter and the D community, I'm adding this is a lowest-priority enhancement in Bugzilla. It's very difficult to find things again in the newgroup. I believe it should remain in this state in Bugzilla until it is either implemented, or it is formally stated that it will not be in DMD 1.0. I suggest that 'Enhancement' be used for any language proposals which receive positive feedback from Walter, and for which discussion has died down. (Note: Bugzilla is not the right forum for discussing language proposals, further discussion on the proposal should take place on the digitalmars.D group. If anyone believes that this is an inappropriate use of Bugzilla, I'll happily comply).

The status of this feature is now clear: it will not be included in D 1.0.

I'd prefer to leave this open as an enhancement request for 2.0. It's a great idea.

New url is: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=35949

yah, it'a great idea. if opSubAssign_r could be automatically deduced from opSubAssign it would be even greater. Then opAddAssign_r would leave in compiler internal. while the possibilities are there: typeof(this) opSubAssign(this, oper) opSubAssign_r would simply as following: tyepof(this) opSubAssign_r(oper, this) and also opDivAssign_r any non-commutative operand would need to have this reverse op. and compiler only need to consider non-commutative situation as we can see in common case, integer , float type , sub and div operators are not commutative. Shall we introduce some *commutative* keyword to let the compiler know if it's okay to call the original op overloading. If not, the compiler would try to call the op_r which is deducing from op overloading.

This is clearly not going to happen. Rejected.