Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only". Something that's const to you might not be const to something else, so you can never depend on it staying the same.

I may be wrong, but my understanding is that Rust's constants are actually constant, and proved as such by the compiler, which is a major difference over C++.

That's right. If you have an `&` reference to something, the language enforces that it will never be mutated as long as that reference is alive. (Also, if you have an `&mut` reference to something, the language enforces that you're the only one who can mutate it while that reference is alive; that's how iterator invalidation is prevented.)

I've often wished for this in C and C++, particularly from an optimization perspective. I always hated that the optimizer cannot assume that the the contents of a struct to which I have a const pointer won't change out from under me when I call another function. It means that it cannot cache members of this struct in callee-save registers; it has to reload them every time.

I don't know how much of a speed difference it would actually make in practice, but it bothers me that I cannot express this in C++.

Rust's "immutable" references ensure that it cannot be changed from either the reference holder or other safe code that has a reference to the same memory region. Note that (as the periodic table suggests) "mutable" references can be downgraded to the immutable references, but the mutable references are locked while the immutable references are active. Once the immutable references are gone (this is checked by the compiler, see the lifetime guide for details) the mutable references can be used again.

Not only is it "read only," it's not even necessarily read only:

  #include <iostream>

  void f(const int* var)
  {
    *var = 42;
  }

  int main()
  {
    int* ptr = new int(78);
    f(ptr);
    std::cout << *ptr << std::endl;
    return 0;
  }

Compiling produces:

  [scott_s@local Code] g++ const.cpp 
  const.cpp: In function ‘void f(const int*)’:
  const.cpp:5: error: assignment of read-only location

But if we make it:

  #include <iostream>

  void f(const int* var)
  {
    int* sneaky = const_cast<int*>(var);
    *sneaky = 42;
  }

  int main()
  {
    int* ptr = new int(78);
    f(ptr);
    std::cout << *ptr << std::endl;
    return 0;
  }

We get:

  [scott_s@local Code] g++ const.cpp 
  [scott_s@local Code] ./a.out 
  42

C++ gives us escape hatches all over the place. I think that the modern approach of compartmentalizing all escape hatches into explicitly regions of "unsafe" code, and providing no escape hatches outside of such regions, is much better.

> Ah, but C++ "const" doesn't do what it says on the tin! What "const" means is not "constant", but "read-only".

Yes and that's a huge trap, which is why I'm so annoyed that D has copied 'const' from C++ instead of renaming it to 'view' or 'read'..

C++ const doesn't actually provide constness for purposes of concurrent access unless you follow a bunch of other rules (no const_cast, no use of "mutable", no use of mutable class statics, no use of mutable file-level statics, no use of mutable globals) that in practice people violate all the time even with const objects.