2

The ++ and -- operators are included in many other languages. Why did the language designers choose not to include these operators in Rust?

Thorkil Værge
  • 2,727
  • 5
  • 32
  • 48
  • 1
    This question is being discussed on [meta](https://meta.stackoverflow.com/questions/415083). – cigien Jan 04 '22 at 18:10

1 Answers1

9

They are not included in Rust as they can lead to subtle bugs because they require complex knowledge about evaluation order, especially when combined into larger expressions as shown below. Can you guess what these two C++ programs print? I guessed wrong.

#include <cstdio>
int main()
{
    int a = 4;
    int b = 4;
    int c = a++ + b++;
    printf ("%i %i %i", a, b, c);
    return 0;
}

#include <cstdio>
int main()
{
    int x = 10;
    int z = ++x + x++;
    printf ("%i %i", x, z);
    return 0;
}

From the FAQ:

Why doesn't Rust have increment and decrement operators?

Preincrement and postincrement (and the decrement equivalents), while convenient, are also fairly complex. They require knowledge of evaluation order, and often lead to subtle bugs and undefined behavior in C and C++. x = x + 1 or x += 1 is only slightly longer, but unambiguous.

Simson
  • 3,373
  • 2
  • 24
  • 38
Thorkil Værge
  • 2,727
  • 5
  • 32
  • 48
  • 2
    I actually think the behavior of the line `int z = ++x + x++;` is undefined in the C++ standard as I found a blog post where it was stated that this should print `12 22`, but in the online compiler I used[1], this prints `12 23`. [0]: https://hackernoon.com/increment-and-decrement-operators-in-cc-6c1c3u63 [1]: https://www.onlinegdb.com/online_c++_compiler, this – Thorkil Værge Jan 04 '22 at 12:01
  • 2
    IIRC this (`a++ + b++`, `++x + x++`) is undefined behavior. Not sure about that though. – Chayim Friedman Jan 04 '22 at 12:02
  • It is worth noting that while in Rust assignments _are_ expressions, they always return the unit type `()`, which prevents whole another class of bugs. Because of that, we could support either of them (there is no reason to support both) but return a unit type (like Go does), but the language designers decided it makes no real difference with `x += 1`. – Chayim Friedman Jan 04 '22 at 12:04
  • 4
    `a++ + b++` is well defined: the compiler may choose in which order it evaluates `a++` and `b++` and whether it computes the addition first before incrementing `a` and `b` or whether it stores the original values of `a` and `b` in temporaries and increments them before performing the addition, but all those will result in `a=b=5` and `c=8`. – Jmb Jan 04 '22 at 13:13
  • 3
    `++x + x++` is ill defined: the compiler may choose to evaluate the increments and the addition in whatever order, which may result in `z` being 21, 22 or 23 depending on the order chosen. – Jmb Jan 04 '22 at 13:17
  • 1
    @Jmb Even worse, `z` can be 0 or 50, and the rest of the program malfunction, because `++x + x++` is UB. – user4815162342 Jan 04 '22 at 13:33
  • @user4815162342 I think in older versions of the C standard it was simply "unspecified", not "undefined". But you're right, at least in [C11](http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf), it is indeed "undefined" and so may result in anything at all (section 6.5). – Jmb Jan 04 '22 at 13:55
  • @Jmb Sometimes it's hard to believe just _how_ easy C and C++ make it to shoot oneself in the foot. I seem to remember `++x + x++` being decried as UB back in the 90s and, while I don't trust my memory too far in such matters, resources like [this 90s FAQ](http://c-faq.com/expr/seqpoints.html) or [this 2009 SO question](https://stackoverflow.com/questions/949433/why-are-these-constructs-using-pre-and-post-increment-undefined-behavior) seem to corroborate it. – user4815162342 Jan 04 '22 at 22:49