Immutability

We've already understood that a certain level of immutability is preferred in C++; the common example is as follows:

class ...{
    int add(const int& first, const int& second) const{
        return first + second;
    }
}

The const keyword clearly communicates a few important constraints on the code, such as the following:

• The function does not change any of its arguments before returning.
• The function does not change any data member of the class it belongs to.

Let's now imagine an alternate version of add, as follows

int uglyAdd(int& first, int& second){
    first = first + second;
    aMember = 40;
    return first;
}

I called this uglyAdd for a reason—I don't tolerate code like this when I'm programming! This function violates the principle of minimal surprise and does too many things. Reading the function code reveals nothing about its intent. Imagine the surprise of the caller, if not careful, then, just by calling an add function, two things changed—one in the parameters passed, and the second in the class where the function is located.

While this is an extreme example, it contributes to an argument for immutability. Immutable functions are boring; they receive data, change nothing in the received data, change nothing in the class containing them, and return a value. When it comes to maintaining code over long periods of time, however, boring is good.

Immutability is the core property of functions in functional programming. Of course, there's at least one part of your program that cannot be immutable—input/output (I/O). We will accept I/O for what it is, and we will focus on increasing the immutability of our code as much as possible.

Now, you are probably wondering whether you have to completely rethink the way you write programs. Should you forget all that you learned about OOP? Well, not really, and let's see why.