What are the problems of bringing C++-like const into a language?

Question

I am interested in the idea of C++-like const not that particular execution (like casting away const).

Take for example C# -- it lacks C++-like const, and the reason for it is the the usual -- people and time. Here additionally it seems the C# team looked at the C++ execution of const, marketing CLR and had enough at this point (see why there is no const member method in c# and const parameter ; thank you Svick). Be if we move further than that, is anything else?

Is there something deeper? Take for example multi-inheritance -- it is usually seen as hard to grasp (for the user) and thus not added to the language (like diamond problem).

Is there something in NATURE of const that pose a problem that it is better for language to avoid it? Something like deciding if const should be deep or shallow (having const container does it mean I cannot add new element or alter existing elements as well; what if elements are of reference type)?

UPDATE: while I mention C#, and thus making a historical perspective I am interested in the nature of potential problems of const to the language.

This is not a challenge of the languages. Please ignore such factors as current trends or popularity -- I am interested only in technical issues -- thank you.

Answer 1

Note sure if this qualifies for you, but in functional languages like Standard ML everything is immutable by default. Mutation is supported through a generic reference type. So an int variable is immutable, and a ref int variable is a mutable container for ints. Basically, variables are real variables in the mathematical sense (an unknown but fixed value) and refs are "variables" in the imperative programming sense - a memory cell that can be written to and read from. (I like to call them assignables.)

I think the problem with const is two-fold. First, C++ lacks garbage collection, which is necessary to have non-trivial persistent data structures. const must be deep to make any sense, yet having fully immutable values in C++ is impractical.

Second, in C++ you need to opt into const rather than opt out of it. But when you forget to const something and later fix it, you'll end up in the "const poisoning" situation mentioned in @RobY's answer where the const change will cascade throughout the code. If const was the default, you wouldn't find yourself applying const retroactively. Additionally, having to add const everywhere adds a lot of noise to the code.

I suspect the mainstream languages that followed (e.g. Java) were heavily shaped by C and C++'s success and way of thinking. Case in point, even with garbage collection most languages' collection APIs assume mutable data structures. The fact that everything is mutable and immutability is seen as a corner case speaks volumes about the imperative mindset behind popular languages.

EDIT: After reflecting on greenoldman's comment I realized that const isn't directly about the immutability of data; const encodes into the type of the method whether it has side effects on the instance.

It's possible to use mutation to achieve referentially transparent behavior. Suppose you have a function that when called successively returns different values - for example, a function that reads a single character from stdin. We could use cache/memoize the results of this function to produce a referentially transparent stream of values. The stream would be a linked list whose nodes will call the function the first time you try to retrieve their value, but then cache the result. So if stdin constains Hello, world!, the first time you try to retrieve the value of the first node, it'll read one char and return H. Afterwards it'll continue to return H without further calls to read a char. Likewise, the second node would read a char from stdin the first time you try to retrieve its value, this time returning e and caching that result.

The interesting thing here is that you've turned a process that's inherently stateful into an object that's seemingly stateless. However, it was necessary to mutate the object's internal state (by caching the results) to achieve this - the mutation was a benign effect. It's impossible to make our CharStream const even though the stream behaves like an immutable value. Now imagine there's a Stream interface with const methods, and all your functions expect const Streams. Your CharStream can't implement the interface!

(EDIT 2: Apparently there's a C++ keyword called mutable that would allow us to cheat and make CharStream const. However, this loophole destroys const's guarantees - now you really can't be sure something won't mutate through its const methods. I suppose it's not that bad since you must explicitly request the loophole, but you're still completely reliant on the honor system.)

Secondly, suppose you have high-order functions - that is, you can pass functions as arguments to other functions. constness is part of a function's signature, so you wouldn't be able to pass non-const functions as arguments to functions that expect const functions. Blindly enforcing const here would lead to a loss of generality.

Finally, manipulating a const object doesn't guarantee that it's not mutating some external (static or global) state behind your back, so const's guarantees aren't as strong as they initially appear.

It's not clear to me that encoding the presence or absence of side effects into the type system is universally a good thing.

Answer 2

The main problem is programmers tend not to use it enough, so when they hit a place where it's required, or a maintainer later wants to fix the const-correctness, there is a huge ripple effect. You can still write perfectly good immutable code without const, your compiler just won't enforce it, and will have a more difficult time optimizing for it. Some people prefer their compiler not help them. I don't understand those people, but there are a lot of them.

In functional languages, pretty much everything is const, and being mutable is the rare exception, if it's allowed at all. This has several advantages, such as easier concurrency and easier reasoning about shared state, but takes some getting used to if you are coming from a language with a mutable culture. In other words, not wanting const is a people issue, not a technical one.

Answer 3

I see the drawbacks as:

• "const poisoning" is a problem when one declaration of const can force a previous or following declaration to use const, and that can cause its previous of following declarations to use const, etc. And if the const poisoning flows into a class in a library that you don't have control over, then you can get stuck in a bad place.

• it's not an absolute guarantee. There are usually cases where the const only protects the reference, but is unable to protect the underlying values for one reason or another. Even in C, there are edge cases that const can't get to, which weakens the promise that const provides.

• in general, the sentiment of the industry seems to be moving away from strong compile-time guarantees, however much comfort they may bring you and I. So for the afternoon I spend touching 66% of my code base because of const poisoning, some Python guy has banged out 10 perfectly workable, well-designed, well-tested, fully functional Python modules. And he wasn't even hacking when he did it.

So maybe the question is, why carry forward a potentially controversial feature that even some experts are ambivalent about when you're trying to gain adoption of your spiffy new language?

EDIT: short answer, a new language has a steep hill to climb for adoption. It's designers really need to think hard about what features it needs to gain adoption. Take Go, for example. Google sort of brutally truncated some of the deepest religious battles by making some Conan-the-Barbarian style design choices, and I actually think the language is better for it, from what I've seen.

Answer 4

There are some philosophical problems in adding const to a language. If you declare const to a class, that means that the class cannot change. But a class is a set of variables coupled with methods (or mutators). We achieve abstraction by hiding the state of a class behind a set of methods. If a class is designed to hide state, then you need mutators to change that state from the outside and then it isn't const anymore. So it is only possible to declare const to classes that are immutable. So const seem only possible in scenarios where the classes (or the types you want to declare const) are trivial...

So do we need const anyway? I dont think so. I think that you can easily do without const if you have a good design. What data do you need and where, which methods are data-to-data methods and which abstractions do you need for I/O, network, view etc. Then you naturally split modules and classes arise that deal with state and you have methods and immutable classes that don't need state.

I think most problems arise with big fat data-objects that can save, transform and draw itself and then you want to pass it to a renderer for example. So you cannot copy the contents of the data, because that is too expensive for a big data-object. But you dont want it to change either, so you need something like const you think. Let the compiler figure out your design flaws. However if you split those objects in only an immutable data-object and implement the methods in the responsible module, you can pass around (only) the pointer and do things you want to do with the data while also guaranteeing immutability.

I know that it is possible in C++ to declare some methods const and to not declare on other methods, because they are mutators. And then some time later you need a cache and then a getter mutates an object (because it lazy loads) and it isnt const anymore. But that was the whole point of this abstraction right? You don't know what state gets mutated with each call.