Why not ++ and –?

One question we occasionally get is why we didn’t introduce C-style increment (++) and decrement (–) operators into the language when we introduced the compound operators (i.e. += and -=). We did consider it, but:

  1. Assignment in VB is always done at the statement level and not the expression level. Introducing a ++ statement and — statement seemed pretty redundant. If you’re going to have “x++” as a statement, why not just use “x += 1”?
  2. If we introduced ++ and — as assignment expressions, then it would be weird not to allow general assignment expressions. For example, in C#, you can say “if ((x = foo()) == 10) {}” and have the assignment done as part of evaluating the if expression. The problem, as you might have already guessed, is that we already use the = operator in expressions for testing value equality. Thus, there would be no easy way to introduce general assignment expressions into the language, which would make it strange that we had — and ++.
  3. Even if we ignored the weirdnesses inherent in having increment and decrement with no assignment, the operators’ main function in C often times seems to be to encourage programmers to write arcane and brittle code. Besides the confusion in meaning between prefix and postfix, the increment/decrement operators usually depend on the order of evaluation of expressions. Which requires remembering the order of evaluation in a particular language, which isn’t always very obvious. For example, in C, what do the following expressions result in? It really depends on the order in which the expressions happen to be evaluated.
a[b++] = b
a[b] = ++b
foo(b++, ++b, b++, ++b)

Overall, we felt we were better off just leaving the increment and decrement operators alone.

20 thoughts on “Why not ++ and –?

    1. paulvick

      Certainly, one can introduce the operators without introducing assignment in expressions, although it seems strange (at least, to me) to have one and not the other. Even given that, though, point #3 still is operative in my mind.

  1. Diego Vega

    Reasons cited in points 1, 2 and 3 make me think that those are some of the few aspects in wich VB is still a more elegant language than any member of the C family, meaning a human programer can understand (this particular) VB code using a smaller set of rules. Syntax that tends to obscure code or that introduces side effects should be kept out of VB in the future. Actually VB has already enough of it.

    C# on the other side is based on C tradition… so it is not actually for human programers 😉

    Last, if you can do a+=1 (which is great) why would you need a++? To save one keystroke each time?

  2. Dave Rothgery

    I don’t like ++/– (for all the reasons Paul mentioned), but I’d think that its advantage over += 1/-=1 is probably only in overloading scenarios (i.e. LinkedListItem++ might give the next item in a LinkedList).

  3. Raj Chaudhuri

    Borland’s Turbo BASIC (and later PowerBASIC) solved the problem Dave mentioned by providing INCR and DECR statements, which could increment numbers or pointers. I guess a similar thing could be done in VB.NET, with INCR and DECR being ICollection-aware. Paul ?

    1. paulvick

      It’s an interesting idea. It’d require a general concept of an "incrementable" type, so it’s more than just a language thing, but something for us to think about…

  4. Jim Adams

    I guess a major reason for implemeting ++ / — would be to make coversion between C# and VB.Net easier. For instance, in the following code snippet that retrieves the TimeToLive value from a DNS MX record, converting to VB.Net is significantly more difficult (and error prone) without ++ operators. And the VB.Net coder is still left to understand how C# ++ operators work anyway. So why not add the option and let the programmer decide.

    C# Code Snippet:

    int ttl = reply[pos++] << 24 | reply[pos++] << 16 | reply[pos++] << 8 | reply[pos++];

    VB.Net Code Snippet:

    dim ttl as integer
    ttl = reply(pos) << 24: pos+=1: ttl = ttl or reply(pos) < 16: pos+=1: ttl = ttl or reply(pos) << 8: pos+=1: ttl = ttl or reply(pos): pos+=1

    As you can see, the VB.Net code is longer, more error prone and less readable. And we didn’t even have to factor in a [++pos] for this example.

    Thanks for your consideration,


  5. Pingback: Panopticon Central

  6. Pingback: Panopticon Central

  7. Jason Knott

    To bring this discussion back up, I know I’ve boggled over translating simplistic C# code into VB.NET many hours since VB doesn’t allow Assignments within expressions. Take the following two C# code pieces:

    while (–n >= 0) {

    //do some code



    while (n– >= 0) {

    //do some code


    Even something this simple becomes difficult to translate, especially if the variable ‘n’ is needed outside the loops.

  8. Sounds Stupid

    VB has always been stupid, so leave it alone.

    There is no need to justify a situation that has existed for so long. Also, that reasoning is very weak and pretends all VB coders are stupid.

    Better off to have said nothing, I feel.

  9. stu


    "x += 1" introduces a magic number.


    the single equals "=" confused the hell outta me the first time I saw it in a parameter expecting a boolean.


    don’t mess with code you don’t know how to read. or, just rewrite it so it makes sense. afterall, it’ll probably only take you 5 minutes worth of effort to figure out how "++x" is different from "x++", then rewrite it however you like.

  10. Peter

    post pre increment isn’t that hard. if you can’t understand it. maybe cs isn’t for you.

    try the following majors




  11. konikula

    I am rather against c++ convence in VB. I am pretty familiar to c+=1. I also don’t agree there is some difficulty to translate c++ iterators to VB. It is simply one two lines more, or some shuffle of them. I was supposing you decided for excluding c++ influence for being assignment instead expression. Also, logically, it is highly confusing to do a[c++] = c … but also I wouldn’t see any reason to confuse myself with such crystalic evil. But I was thinking, many times, about some alternative, eg function Inc c by reference, which would optionally miss brackets to show c++ coders we are not stupid? ReDim also doesn’t have bracket, although I know its difficult to call it function or also statement… In this case, I am not familiar to it, but it is logic, it is possible to allow ++i, but it would be just equal to Sub Inc(counter As Integer). Also in this piece of theory rises interesting problem: would it be possible to "place" ++i or Inc i inside expression, so that it would not affect result: somehow be considered to be ISOLATED EXPRESSION STATEMENT… Also I would like to see such Sub with literally ByRef Counter As Integer, while it would confuse c++ code to vb recoders much more 🙂 … I would not make such confusions elsewhere, so that such Inc or `++` i would work with all numeric types… Friendly regards, Matt


    Visual Basic is not stupid. Language is never stupid, until it has evolution and users. ("Being a cow is stupid"?)

  12. Undefined Behaviour

    "For example, in C, what do the following expressions result in? It really depends on the order in which the expressions happen to be evaluated."

    Actually, no. In each case, the expression results in undefined behaviour. An object cannot both be modified and read between two sequence points.


    It is of course up to Visual Basic designers how they design their language, but comparing it with illegal code examples from another language seems unreasonable. Your first two reasons are reasonable.

  13. Will

    unfortunately, vb’s syntax is not the best. It’s just the way it is. Its great as a begginer language, but it lacks so much small, but useful details.

  14. Anefeletos


    Maybe ++ and — is usually redundant, but "+=" and "-=" vb operators have not the same usage as in C#: we can’t use "Dim k=(x+=2)+3"

    The example "while (–n >= 0) {…" answers merely to the usefulness of expression-level assignment operators (let say "ELAOs"). It could be n-=1>=0 also (only in c# supported)

    I think the "+=" and "-=" could be included in vb as ELAOs.

    The prefix ELAOs are more useful, especially because you avoid to loop back in your code lines to initialize your variant, whereas the postfix ELAOS can be fixed easily in the next line of code.


    Although the initial question is "Why not ++ and –?" and the mark that the use of sole equation operator as assignment operator conflicts with the ELAOs idea is rather off-topic, it’s a bit interesting. Whether or not the "+=" operator belongs to the double digit operators, so it remains, I thing, as ELAO candidate in VB.

    3: The third point is the most significant. The simplicity is the main property of a/the philosophy, because allows to simplify our efforts and our thoughts.
    But for the case of "+=" and "-=" as postfix ELAOs candidates in VB I have two points to mark. Firstly, the occurrence of a different shape operator (+ or -) on the side eliminates the risk of misreading it (It’s not that the case with == or — / ++ is more discreet). Secondly there are no major prefix-postfix issues except for the declaration of += / -= as postfix ELAOs.

    Finally about the last three:
    a[b++] = b
    a[b] = ++b
    foo(b++, ++b, b++, ++b)

    Regardless the computation order I think no one will dare to use these expressions without make it certain. But I think the concept should be the one used in System.Threading.Interlock class: First we make clean which array position is going to be altered and then we compute the assignment value: From left to right (except for English, Arabs and Hebrews – Chinese can use both, plus vertical)
    Have a good time


Leave a Reply

Your email address will not be published. Required fields are marked *