From this post (and not only) we got to the point that the ++ operator cannot be applied on expressions returning value.
And it’s really obvious that 5++ is better to write as 5 + 1. I just want to summarize the whole thing around the increment/decrement operator. So let’s go through these snippets of code that could be helpful to somebody stuck with the ++ first time at least.
// Literal
int x = 0++; // Error
// Constant
const int Y = 1;
double f = Y++; // error. makes sense, constants are not variables actually.
int z = AddFoo()++; // Error
Summary: ++ works for variables, properties (through a synthetic sugar) and indexers(the same).
Now the interest part – any literal expressions are optimized in CSC and, hence when we write, say
int g = 5 + 1; // This is compiled to 6 in IL as one could expect.
IL_0001: ldc.i4.6 // Pushes the integer value of 6 onto the evaluation stack as an int32.
For 5++ doesn’t mean 5 becomes 6, it could be a shorthand for 5 + 1, like for x++ = x + 1
What’s the real reason behind this restriction?
int p = Foo()++ //? yes you increase the return value of Foo() with 1, what's wrong with that?
Examples of code that can lead to logical issues are appreciated.
One of real-life example could be, perform one more actions than in the array.
for (int i = 0; i < GetCount()++; i++) { }
Maybe the lack of usage opts compiler teams to avoid similar features?
I don’t insist this is a feature we lack of, just want to understand the dark side of this for compiler writers perhaps, though I’m not. But I know c++ allows this when returning a reference in the method. I’m neither a c++ guy(very poor knowledge) just want to get the real gist of the restriction.
Like, is it just because c# guys opted to restrict the ++ over value expressions or there are definite cases leading to unpredictable results?
In order for a feature to be worth supporting, it really needs to be useful. The code you’ve presented is in every case less readable than the alternative, which is just to use the normal binary addition operator. For example:
I’m all in favour of the language team preventing you from writing unreadable code when in every case where you could do it, there’s a simpler alternative.