Postfix increment operator bug? (No)

[CommonLoon102]

Here is this operator: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/arithmetic-operators#postfix-increment-operator

It says it will increment the value by 1, effective on next line, but it doesn't do it for me (.NET 5 is used):

using static System.Console;

int i = 1;
i += i++ + 1;
WriteLine(i);

It should write 4, but it writes 3 instead.

In C++ it works fine:

#include <iostream>

int main()
{
    int i = 1;
    i += i++ + 1;
    printf("%i\n", i);
}

C++ prints 4 as expected.

[333fred]

This, iirc, is undefined behavior in C++. In C#, it is well-defined: It increments the value of i at the time you used the ++ operator after the expression is evaluated. The sequence of operations that is evaluated looks like this, fully written out:

int i = 1;
int tmp = i;
i = tmp + 1; // This is the ++
i = tmp + 1; // This is the +=

[CommonLoon102]

Maybe the i++ is losing its effect here: i = i + (i++ + 1). More precisely after "solving" the expression in the parentheses. i will be 2 there, after (i++ + 1) evaluates to 2. But then i + 2 should become 2 + 2, which still gives 4, although by a different reasoning. 3 doesn't make any sense anyhow I look at it. Can you give an example how this makes any sense to be 3?

That's precisely what's happening. The tmp variable is how the feature works: i++ saves the current value into a temp, then increments i. However, C# follows a strict left-to-right order of evaluation (another thing that is undefined in C++). So here's the full psuedocode, temps and all, for i += i++ + 1:

int tmp1 = i; // This is the starting read of the left-most i, which is the target of the +=
int tmp2 = i; // This is the starting read of the middle i, the i++
i = tmp2 + 1; // This is the increment of the middle i, the i++
i = tmp1 + tmp2 + 1; // This is the final assignment to i, which is the saved value from the initial read on the left side of the compound operator, the saved value from i++, and 1

Maybe this would be the case if it was ++i instead of i++.

[333fred]

Maybe this would be the case if it was ++i instead of i++.

No. This is what would happen if you did ++i:

int tmp1 = i;
int tmp2 = i;
tmp2 = tmp2 + 1; // Note that this assigns to tmp2
i = tmp2; // This is new
i = tmp1 + tmp2 + 1;

[333fred]

To be clear: the answers I'm showing you are how C# is specified to work. This is all very well-defined behavior in C#. It can be surprising; the ++ and -- operators are not well-understood by users because they have all this odd behavior around temp variable storage, differences between specifying the operator before/after the variable, and differences in behavior from languages like C and C++ (both of which have implementation-dependent behavior and the resulting code formatting your hard drive is a valid thing the compiler could choose to do). You generally shouldn't use them as part of a larger expression, IMO: += is far more understandable.

[CommonLoon102]

i += i++ + 1; and i += i + 1; gives the same result. How can it be? Why the compiler doesn't give a warning? Or at least a code-fix about that I have unnecessary code what could be removed (like in case of unnecessary parentheses)?

[333fred]

How can it be?

Because the code that is emitted works exactly like I said it does.

Why the compiler doesn't give a warning? Or at least a code-fix about that I have unnecessary code what could be removed (like in case of unnecessary parentheses)?

Because we haven't felt that it's important enough of a scenario to devote time to identifying and issuing a warning for.

[CyrusNajmabadi]

Fwiw, this is undefined in c++. Compilers are free to return any result here (or crash if they want). In c# this is actually well defined code that will result in the same behavior always (modulo compiler bugs).

[CyrusNajmabadi]

Darn. Beaten by Fred!

[CommonLoon102]

Fwiw, this is undefined in c++. Compilers are free to return any result here (or crash if they want). In c# this is actually well defined code that will result in the same behavior always (modulo compiler bugs).

For me it looks funny that even the operator what C++ got its name from, is undefined in C++. Tells a lot about the language, LOL!

[CommonLoon102]

Some cases are not undefined behavior anymore (since C++17), see the reference here:
https://en.cppreference.com/w/cpp/language/eval_order

[bernd5]

Here you find a good description: https://stackoverflow.com/questions/54674728/is-there-an-explanation-for-inline-operators-in-k-c-k-c/54677275#54677275

The expanded version of your code is:

int i = 1;
int eval_i = i; //eval_i = 1
int incrementI = i++; //incrementI is 1 - but i is 2
i = eval_i + (incrementI + 1); //incrementI  + (incrementI  +1) = 1 + (1 + 1) = 3
System.Console.WriteLine(i);

[CommonLoon102]

Multiple persons have contributed many good and some better answers. Let me recap it here and then accept my own answer.
First thing, to not mix up operator precedence and expression evaluation order. Expressions are evaluated from left-to-right. Check this comment by Eric Lippert:
https://stackoverflow.com/questions/54674728/is-there-an-explanation-for-inline-operators-in-k-c-k-c/54677275#comment96149488_54677275

The C# spec mentions that the i variable in this case is evaluated only once:
https://www.ecma-international.org/wp-content/uploads/ECMA-334_5th_edition_december_2017.pdf
Check 12.18.3 Compound assignment from page 214.

The term “evaluated only once” means that in the evaluation of x op y, the results of any constituent expressions of x are temporarily saved and then reused when performing the assignment to x. [Example: In the assignment A()[B()]+=C(), where A is a method returning int[], and B and C are methods returning int, the methods are invoked only once, in the order A, B, C. end example]

So in my example, if I put the actual values for the variables the expression i += i++ + 1 (where i=1 initially) would become:
1 += 1 + 1 => 1 = 1 + 1 + 1.
Which gives i = 3. i won't be updated by the i++ because i only evaluates once. Therefore the ++ postfix operator won't do anything at all in this case, its result goes to void (the result of the incrementation won't used for anything), or who knows where, but it won't have any effect.

Another good example would be this:

int[] a = new int[]{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 };
int j = 0;
a[j] += j++ + 1;

It would be a[0] += 0++ + 1 => a[0] = 1 + 0 + 1.
What would give that a[0] is 2, and it is indeed.

Bonus:
i += ++i + 1 would evaluate to 4, because ++i increments i before the i from the ++i sub-expression evaluates. So that's it.

If I wrote something stupid, or something needs to be fixed, please let me know in the comments.

[CommonLoon102]

Java has a similar behavior: https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.7

Example 15.7.1-2. Implicit Left-Hand Operand In Operator Of Compound Assigment

[bernd5]

Nearly correct - just your "Bonus" is wrong. i on the left hand side of += is evaluated first - before ++i.

Here you can see the expanded code:

int i = 1; //i = 1
int eval_i = i; //eval_i = 1;
int increment_i = ++i; //increment_i = 2, i = 2
i = eval_i + (increment_i + 1); //1 + 2 + 1 => 4
System.Console.WriteLine(csn_eval_order_130_8);

And don't worry - it is really not easy. But as a general rule you can stick to "from left to right".

[spydacarnage]

Therefore the ++ postfix operator won't do anything at all in this case, its result goes to void, or who knows where, but it won't have any effect.

It's not that it goes to void - it's similar to using int.TryParse("1", out int x) as a statement - the bool is generated, it's returned, but you're just ignoring it. The same is applying with the i++ - it is doing the sum, but after you use the value, and is then assigning the new value (3) to the original i, thus wiping out the fact that i has, in the meantime, been incremented.

[CommonLoon102]

Nearly correct - just your "Bonus" is wrong. i on the left hand side of += is evaluated first - before ++i.

Here you can see the expanded code:

int i = 1; //i = 1
int eval_i = i; //eval_i = 1;
int increment_i = ++i; //increment_i = 2, i = 2
i = eval_i + (increment_i + 1); //1 + 2 + 1 => 4
System.Console.WriteLine(csn_eval_order_130_8);

And don't worry - it is really not easy. But as a general rule you can stick to "from left to right".

Yeah, it is important to know which expression is it what it evaluates before. The whole expression on the line, or before which subexpression of it? I'm still confused about this. But it seems it evaluates before ++i. I mean.. it is even hard to write down, but you have shown it well.