Why no ++?

Oddly enough, my posting on how to handle a mad crush has become the third most popular article I've written so far.  Who knew there were so many 10 year old girls interested in programming language design? I may have to turn this into an agony column. I've posted some more techniques for handling a mad crush, for the benefit of all you 10 year old girls reading my blog. 

Let's consider just one small example. VB6 did not have the += operator familiar to all C-like-language developers. In VB6 if you wanted to add ten to a number you said

And indeed, VB.NET has this operator.

Since incrementing a variable by one is also an extremely common operation, C-like languages have an even more compact syntactic sugar for this operation: x++ or ++x

When the decision was made to add the += operator to VB.NET, one of our consultants commented

Actually, it isn't as natural as you might think, because VB.NET and C# are NOT mere syntactic variations on each other, and nor should they be. The reason why VB.NET doesn't have the increment operator illustrates the difference in spirit between VB.NET and C#. In fact, it is NOT the case that a C-like k++ is syntactic sugar for a VB-like k += 1 This is because in VB there has always been a strong line drawn between statements and expressions. Not so in languages like C. This is a perfectly legal C (and, for that matter, JScript) fragment, for instance:

k += 1 is an expression in C which returns the assigned value and as a side effect assigns the value to k (and then to x). Most sensible people never use this fact about the += operator, but it is nonetheless true in C because C makes weak distinctions between statements and expressions.

That's not the case in VB.NET. In VB k += 1 is not an expression, it is a statement, and ne'er the twain shall meet.  Such a bizarre construction is a syntax error in VB.NET.

But k++ is an expression. You can say in C

And get both the side effects (two increments), the multiplication and the assignment to x. This is an extremely common usage in C-like languages, so if we were going to add the ++ operator, then developers would expect that k++ is an expression in VB.NET, not a statement. (The fact that they are expressions explains why there are two forms -- one form returns the value of the variable before it is incremented, the other after.)

If you make the increment operator only legal in statements -- alone on a single line -- then saving that keystroke is clearly not worth the testing effort that would go into this -- much less the dev effort, the documentation effort, the localization effort, the specs that would have to be written, etc.

Consider a hypothetical world in which k++ and ++k are legal expressions. We would have to come up with some definition of what this code does:

First of all, what numbers get passed to Foo? Is this the same as

z = Foo(100, 101) -- stick k on the stack, do ++k, stick k on the stack, do k++

z = Foo(100, 102) -- stick k on the stack, do k++, do ++k, stick k on the stack

z = Foo(101, 101) -- do ++k, stick k on the stack, stick k on the stack, do k++

Second, does the k++ pass a reference to k to the byref parameter, or does it pass it by value? Suppose it passes it by reference -- then what does k equal when Foo returns? Do we do it like this:

Stick k on the stack, do ++k, stick k on the stack, do k++, call Foo, assign 10 to k

Stick k on the stack, do ++k, stick k on the stack, call Foo, assign 10 to k, do k++, so it's 11.

Or, if it passes by value then k is never set to 10, so we're fine -- k is definately 102 when we're done as it is incremented twice.

We could come up with some answers to these questions, but they would be rather arbitrary. The answers are apparently sufficiently inobvious that the C++ standard leaves several of them unanswered, and therefore such code is not portable! The question about function parameter list evaluation order is dismissed as "The order of evaluation of arguments is undefined; take note that compilers differ. The order of evaluation of the postfix expression and the argument expression list is undefined." The question about whether k++ runs before or after the function runs is answered: "All side effects of argument expressions take effect before the function is entered" And with regard to whether k++ returns a reference to k -- in C++, the ++ and -- operators take lvalues and return lvalues, so yes, if VB.NET worked like C++ in this regard, evaluating k++ as an argument would have to pass a reference to k to a function expecting a byref argument.

k++ simply is not very BASIClike. Maybe that marks me as hopelessly old-fashioned that I'm saying that anything is not BASIClike when we have a BASIC that has object polymorphism! Call me old-fashioned then -- but I think that VB.NET is not and should not be "C# without braces" and that there are expression idioms which don't particularly make sense in VB. Heck, I would argue that ++ is an idiom which does not work particularly well in C, C++, Java, JScript or C#. Sure, ++ in C lets you write very dense code that can only be read if you understand the particular idiom of C -- but dense code is not necessarily fast code or maintainable code or readable code or correct code. Personally I only ever use ++ in loop incrementers and when walking strings a byte at a time -- I'll gladly change ++'s to +=1's.

I'm all for adding syntactic sugar that makes code less verbose. += is a great example of that as it adds nothing new to the language, it just makes an existing common operation lexically shorter. It's a real sugar. But increment operators are not mere sugar; they add new functionality, opening up immense cans of worms at huge cost for small gain.