http://d.puremagic.com/issues/show_bug.cgi?id=1596



--- Comment #10 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-07-08 16:07:37 PDT ---
>- If it's typeof(this), the AssignExpression calls this op*Assign, sets the lvalue to what op*Assign returns and then returns it.

That would be a _bad_ idea. On some level, it defeats the purpose of op*Assign in the first place. There are cases where it is more efficient to do the operation and assign in one operation. Your suggestion basically relegates to op*Assign to being another opBinary except that it allows for the compiler to replace a op= b with a = a op b. Assignment _needs_ to be part of the implementation of op*Assign. That's part of the point. Yes, the return value of op*Assign should be the same as the value as the lvalue, but getting the return value and then doing the assignment makes op*Assign pretty much pointless. If that were the proper way to do it, we wouldn't have op*Assign in the first place. We'd just create op= from opBinary and opAssign. And that's _not_ what we want.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1596



--- Comment #11 from Stewart Gordon <smjg@iname.com> 2011-07-08 16:42:24 PDT ---
I'm not sure you get the point.  It's to give the class designer the choice between in-place modification and creating a new object as the implementation of op=.

OK, so a op= b ought to be automatically equivalent to a = a op b in the absence of an opOpAssign.  So the rule would be to define opOpAssign iff you want it to modify in-place.  But this still doesn't cover cases where whether the modification is in-place isn't a compile-time constant.  Look at how ~= works for instance.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------