> D's const is also transitive, meaning that if something is const, then everything it contains or refers to is also const. If D code has the equivalent of const vector<T*>, then not only is the container treated as const, but the elements are as well.<p>And that is not necessarily what the programmer wants.<p>There are a number of uses for a constant vector and non-const objects. Adding "const" in front of "T" should make everything constant, but just assuming everything is constant does not allow one to have non-const objects.<p>Unless there is a way to override this, it looks like a severe limitation in the language.
> All of this means that const actually provides zero guarantees about an object not being mutated (and even in the case where the object is directly constructed as const, that just means that it's undefined behavior when the object is mutated, not that the compiler actually protects against it being mutated).<p>if this is the only reason why author thinks that const is a problem, then it is all good. you can do the same thing in C as well. and ofcourse, if you do that, and break things, you get to hold all the pieces as well :)<p>probably a 'constexpr' semantics is what the author might be looking for ?<p>arne-mertz article on mutable, available here: <a href="https://arne-mertz.de/2017/10/mutable/" rel="nofollow">https://arne-mertz.de/2017/10/mutable/</a>, which imho, is another side of the const-coin, is quite good as well.<p>edit-001 : slight change.
> <i>Now, Java also added a number of nice things that C++ didn't have - such as an array knowing its own length, array bounds checking, and other features geared towards protecting the programmer from stupid mistakes.</i><p>C++ has bounds-checked arrays that know their length if you want (hello, <i>std::vector<T></i>, or roll your own if you don't like that one). It just doesn't endow the C arrays with it (for good reasons). The C compatibility of C++ means that C++ interoperates easily with C API's without the overhead of FFI.
I'm more annoyed that const is opt-in instead of the default.
Though I guess for C++ as a "better C" there wasn't much of an option to do that...
const is one of the reasons why I prefer strongly-typed languages based on reference types. I want to love the no-overhead policy of C++, but value types make const annoying (e.g. no vector<const string>) and require complicated rvalue-reference mechanics to be efficient when working with nested data structures.<p>In Java, where everything is an (expensive) reference type, building an immutable LabeledPoint2D class is a no-brainer. "final String label; final double x, y;" - done. I find this much easier to reason about than the C++ equivalent where the const-ness only emerges from how you use the class.<p>Add Objective-C's system where Array<T>, Set<T>, String etc. are all immutable, and only their derived types (MutableArray<T>, MutableSet<T>, MutableString) are mutable, and you get a reasonably effective and efficient implementation of tail-constness without extending your type system.<p>It's bizarre how C++ and D both try so hard to implement const, yet higher-level languages that could easily have better const support don't really bother (think Java, where you never know which List<T> is mutable).