Timeline for Why it is not possible to overload compound assignment operator in C#?
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 8, 2022 at 8:03 | history | edited | Glorfindel | CC BY-SA 4.0 |
broken link fixed, cf. https://meta.stackoverflow.com/a/406565/4751173
|
| Jul 7, 2015 at 0:23 | audit | Close votes | |||
| Jul 7, 2015 at 0:23 | |||||
| Jun 21, 2015 at 19:24 | audit | Close votes | |||
| Jun 21, 2015 at 19:24 | |||||
| Jun 11, 2015 at 13:34 | audit | Close votes | |||
| Jun 11, 2015 at 13:34 | |||||
| Jun 3, 2015 at 6:52 | vote | accept | greenoldman | ||
| May 31, 2015 at 5:02 | comment | added | jpmc26 |
@Deduplicator How in the world does a+=b not make sense with immutable strings? I would expect it to concatenate then and assign the new result to the variable. I would always expect that a + operator generates a new object instead of modifying one in place; doing anything else is just poor design. As for preserving identity with a+=b, you could use an internal cache (similar to string interning) to fetch an existing value during +, thus preventing duplication. The semantics of += make no sense unless the semantics of + make sense.
|
|
| May 30, 2015 at 18:26 | comment | added | greenoldman | @Telastyn, I am afraid of that too :-). | |
| May 30, 2015 at 18:00 | answer | added | Telastyn | timeline score: 14 | |
| May 30, 2015 at 17:52 | comment | added | Telastyn |
@greenoldman - I understand that motivation, but personally, I would find *= mutating a reference type to be semantically incorrect.
|
|
| May 30, 2015 at 17:32 | history | tweeted | twitter.com/#!/StackProgrammer/status/604701885556211712 | ||
| May 30, 2015 at 17:24 | comment | added | JacquesB | Eric Lippert would probably point out that any feature is unsupported until somebody decides to support it. So for any supported feature there is some reasoning behind it, but for unsupported features they might not necessarily be a design choice behind the lack of support. Perhaps nobody thought of including it? | |
| May 30, 2015 at 16:43 | comment | added | Ixrec | @Deduplicator Agreed. I was only responding to the issue of having + call += versus += calling +, on the assumption that you already needed/wanted to implement both operators. | |
| May 30, 2015 at 16:43 | history | edited | svick | CC BY-SA 3.0 |
edited title
|
| May 30, 2015 at 16:41 | comment | added | Ixrec | @greenoldman Ideally, the innards of C# are smart enough to perform that optimization when automagically writing the += operator. I'm not a C# guy so I have no idea if they are. Perhaps we should ask Jon Skeet about that. | |
| May 30, 2015 at 16:40 | comment | added | 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. | |
| May 30, 2015 at 16:38 | comment | added | greenoldman |
@Ixrec, thank you very much for fixing my terminology :-). Also thank you for noticing the natural flow, with defining += first there is some nasty side-effect in reference world, that X op= Y is no longer a shortcut to X = X op Y. And I am frightened that this optimization is not worth destroying this notion (I am designing my own language).
|
|
| May 30, 2015 at 16:35 | history | edited | greenoldman | CC BY-SA 3.0 |
edited body; edited title
|
| May 30, 2015 at 16:33 | comment | added | 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. | |
| May 30, 2015 at 16:30 | comment | added | Ixrec | I believe the term for these is "compound assignment operators". | |
| May 30, 2015 at 16:27 | comment | added | greenoldman |
@Telastyn, no (it is pretty old), but excluding some commutative problems, you would usually go with pattern "define one, get others for free". So you usually define pre-increment operator, less operator and op-assignment operators, and the rest is built upon those. I don't want to deal with this topic further, so as an example make an experiment, define * and then *= for a 1000x1000 matrix, where RHS parameter is float. And then reverse dependency of those operators.
|
|
| May 30, 2015 at 16:18 | comment | added | 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?
|
|
| May 30, 2015 at 16:12 | history | edited | greenoldman | CC BY-SA 3.0 |
deleted 3 characters in body
|
| May 30, 2015 at 16:07 | history | asked | greenoldman | CC BY-SA 3.0 |