On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote: [...] > The reality is though, that D's const is not actually very useful, and > C++'s const is.
Actually, I think C++ const is not very useful, because it guarantees nothing. At the most, it's just a sanity checker to make sure the programmer didn't accidentally do something dumb. But given an opaque C++ function that takes const parameters, there is ZERO guarantee that it doesn't actually modify stuff behind your back, and do so legally (per spec). I mean, how many times have you written const_cast<...> just to get a piece of code to compile? I know I've been guilty of this in many places, because it simply isn't worth the effort to track down all the places of the code that you need to fix to make it const-correct. So basically, C++ const is nothing more than an annotation that isn't really enforced. But you're spot on about D's const, though. While D's const *does* provide real guarantees (unless you tread into UB territory by casting it away), that also limits its scope so much that it's rarely useful outside of rather narrow confines. Yet because it's so strict, using it requires investing significant effort. So you end up with the unfortunate situation of "a lot of effort" + "limited usefulness" which for many people equals "not worth using". > D has no way to express head-const, and it turns out it's a > tremendously useful concept. I can live without head-const... but what *really* makes const painful for me is the lack of head-mutable. I.e., given a const container (which implies const objects), there is no universal way to obtain a mutable reference to said const objects, unless you tread into UB territory by forcefully casting it away. This makes const so limited in applicability that, for the most part, I've given up using const at all, in spite of having tried quite hard to use it as much as possible for years. [...] > I've also had occasional success refactoring to support const, but > it's certainly the case that success is not guaranteed. And it's > always time consuming regardless. Yes, it's time-consuming. And takes significant effort. In spite of being rather limited in applicability. In my experience, it's useful for isolated pieces of code near the bottom of the program's call chain, where there is little or no additional dependencies. But it's just too cumbersome to use at any higher level, and a royal pain in generic code (which I'm quite heavy on). It probably *can* be made to work in most cases, but it falls under my umbrella category of "too much effort needed, only marginal benefits, therefore not worth it". T -- A linguistics professor was lecturing to his class one day. "In English," he said, "A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative." A voice from the back of the room piped up, "Yeah, yeah."
