> Immutability is stronger than C++ const correctness and easier to use at the same time.

C++-style const appears to be stronger than just immutability, since you can have immutable objects in C++, but you can also pass const references to mutable objects.

A const reference to a mutable object doesn't guarantee that the object won't change contrary to an immutable object. Hence const is weaker than immutable.

You can have immutable objects in C++, but C++ offers almost nothing to make dealing with such objects fast and easy. Also the lack of GC makes designing persistent data structures an order of magnitude harder task than in most other languages.

That's only if you do not use a library and/or have no idea how shared_ptr is implemented.

The standard library doesn't come with persistent collections included. Just the fact that they are not standard like in some other languages, causes fragmentation.

As for shared_ptr, they are a good idea when you don't care about performance. And they don't solve cycles, which may appear in some structures (e.g. graphs).

That's because it is undefined behavior to cast a const object to a non-const object. Instead, you must tell the compiler via the mutable keyword or else it will make optimizations based on the assumption it can't change.

Precisely why it's harder to use. C++ is more expressive, and thus creating self-consistent designs is harder.

C++ is more expressive than what? Than C probably. Than Java/C# - arguable. Than Scala/Haskell/Rust/Python/Ruby/R - no way.

More expressive than Java, sure. Java doesn't have overloaded operators, or cv-qualifiers, or templates, or many many many other things that make the type design space more expressive.

Ruby is hardly expressive at all in this respect - you can express to the interpreter very little about types, and the interpreter won't help you much at all.

C++ doesn't have GC, reflection, annotations, code generation utilities (annotation processors, cglib, etc), first-class generic types, existential types, rich standard library etc. That's why it is "arguable".

> you can express to the interpreter very little about types

Dynamic types are still types. Only the error detection moment is different, but lack of static types doesn't mean low expressivity.

in which of these languages can you have types depending on values ? :=)

In Scala and Idris. Haskell has no direct support, but I believe you can get quite close with rank-2 types.

Also, typing is not the end of all the things. Most languages I listed have much stronger metaprogramming capabilities than C++. Scala, Rust, Template Haskell macro systems are superior to C++ templates.

You'll have to give me an example for that. Having static types is more expressive than not having static types, but I think types make designs easier to make and understand. const is just another layer to the type system.

It's another aspect of type design you need to make decisions for. If you can't see that, I can't help you.

> Const correctness in C++ is a nice feature, but to say it is missing in many other languages is a bit exaggeration. Many other languages offer a much superior tool - immutable data types. Immutability is stronger than C++ const correctness and easier to use at the same time.

Technically C++ const can be used to implement immutable types just as they exist in other languages (and can be hidden behind a library entry point) but I agree that conceptually it's easier to think of an immutable string or vector as an inherent property of the object rather than one applied. And in C++ I don't think you can prevent casting away constness.

> Templates are nowhere near capabilities and ease of use of languages with proper (read: not accidental) macro/metaprogramming systems (e.g. Lisps) or languages with modern generic type systems designed from the ground up (Haskell, Scala/Dotty, Idris, etc). Templates are IMHO a powerful hack, but hack is still a hack with all the consequences - terrible error messages, slow compile times, difficult debugging, late error detection, a lot of accidental complexity caused by templates not being first-class citizens etc.

Templates were not an accidental hack for macros; as Stroustrup once said to me, "the ecological niche of 'macro' had already been polluted so templates were my only way to put macros into the language." I agree it sucks next to lisp macrology (but as a lisp developer since the 1970s I would say that wouldn't I?) but hell, the language makes a distinction between expressions and statements so there's only so much you can do.

> And in C++ I don't think you can prevent casting away constness.

Well, UB prevents you from doing it if the object is originally const.

My bigger gripe with the C++ (and C) const system is the lack of transitivity. A function taking a const X& may still modify e.g. the contents of an exposed pointer member of X.

Is there a language with this behavior? I would find that very confusing.