Why it is not possible to overload compound assignment operator in C#?

Question

The title is be misleading, so please read entire question :-).

By "compound assignment operator" I have in mind a construct like this op=, for example +=. Pure assignment operator (=) does not belong to my question.

By "why" I don't mean an opinion, but resource (book, article, etc) when some of the designers, or their coworkers, etc. express their reasoning (i.e. the source of the design choice).

I am puzzled by asymmetry found in C++ and C# (yes, I know C# is not C++ 2.0) -- in C++ you would overload operator += and then almost automatically write appropriate + operator relying on previously defined operator. In C# it is in reverse -- you overload + and += is synthesised for you.

If I am not mistaken the later approach kills a chance for optimization in case of actual +=, because new object has to be created. So there has to be some big advantage of such approach, but MSDN is too shy to tell about it.

And I wonder what that advantage is -- so if you spotted explanation in some C# book, tech-talk video, blog entry, I will be grateful for the reference.

The closest thing I found is a comment on Eric Lippert blog Why are overloaded operators always static in C#? by Tom Brown. If the static overloading was decided first it simply dictates which operators can be overloaded for structs. This further dictates what can be overloaded for classes.

• Telastyn: Do you have a link for the new C++ style? Naively, overloading += first seems absurd; why would you overload a combined operation rather than the parts of it?
• Ixrec: I believe the term for these is "compound assignment operators".
• Ixrec: @greenoldman Telastyn was probably implying that implementing += in terms of + seems more natural than the other way around, since semantically += is a composition of + and =. To the best of my knowledge, having + call += is largely an optimization trick.
• Deduplicator: @Ixrec: Sometimes, a+=b makes sense, while a=a+b doesn't: Consider that identity might be important, an A cannot be duplicated, whatever. Sometimes, a=a+b makes sense, while a+=b doesn't: Consider immutable strings. So, one actually needs the ability to decide which one to overload separately. Of course, auto-generating the missing one, if all neccessary building-blocks exist and it's not explicitly disables, is a good idea. Not that C# allows that atm, afaik.
• Telastyn: @greenoldman - I understand that motivation, but personally, I would find *= mutating a reference type to be semantically incorrect.

Answer 1

I can't find the reference for this, but my understanding was that the C# team wanted to provide a sane subset of operator overloading. At the time, operator overloading had a bad rap. People asserted that it obfuscated code, and could only be used for evil. By the time C# was being designed, Java had shown us that no operator overloading was kind of annoying.

So C# wanted to balance operator overloading so that it was more difficult to do evil, but you could make nice things too. Changing the semantics of assignment was one of those things that was deemed always evil. By allowing += and its kin to be overloaded, it would allow that sort of thing. For example, if += mutated the reference rather than making a new one, it wouldn't follow the expected semantics, leading to bugs.

• greenoldman: Thank you, if you don't mind I will keep this question open bit longer, and if nobody beat you with the reasoning of actual design, I will close it with accepting yours. Once again -- thank you.
• Telastyn: @greenoldman - as well you should. I too hope someone come with a answer with more concrete references.
• Deduplicator: So, this is a place where the impossibility of talking both about the pointer and the pointee comfortably and unambiguously rears it's head? Damn shame.
• Den: "People asserted that it obfuscated code" - it's still true though, have you seen some of the F# libraries? Operator noise. E.g. quanttec.com/fparsec