For example, again referencing Erlang since that's the only FP language I'm well-versed in, immutable data + pattern matching means that there are assertions on practically every line of code in production.
In C++, any "const" data can only have "const" operations operate upon them.
const int x = 20;
x = 30 ; // Compile Error, not a const operation.
int y = x + 20; // Allowed
If you have a class:
class Foo{
public:
const int x;
int y;
Foo(int initial): x(initial), y(initial){
}
void setY(int value){
y = value;
}
int getXPlusY() const{
return x + y;
}
};
Foo f(20); // Allowed
f.x = 30; // Compile Error, not a const-operation
int y = f.x + 30; // Allowed
const Foo f2(20); // The f2 object is now const. Non-const routines are no longer allowed
f2.setY(30); // Not a const-routine.
int bar = f2.getXPlusY(); // Allowed, getXPlusY is a const-function
-----------------
So yes. Every single line of code you write will be double-checked by the compiler to see if it is "const-correct". That's the advantage of multi-paradigm languages like C++. Its not "pure", but it implements ideas like immutability from other languages.
That gives you immutability on that instance, but the benefits are diminished since the language is not immutable-first. If it were, I’d expect f2.setY(30) to return a new immutable instance of Foo with x == 20 and y == 30. As it stands, there’s not a reliable way to get “an immutable Foo instance with everything the same except for y, which has this new value.”
For a class with two properties, you can make a new constructor that initializes both, though it’s a bit unwieldy. It becomes unworkable when you have five or ten properties. A more data-oriented approach would be to use a key/value map, and have standard functions to “update” map members by returning new maps with the “updated” value(s). Those libraries probably exist for C++, but you have to enforce their use, whereas languages that are built around those concepts provide stronger guarantees from the outset.
Suppose get_data will get N or less pieces (if N pieces of data aren't available) of data and return, as a tuple, both the amount of data obtained and the data. The above assignment is actually part of Erlang's pattern matching, the second use of N (on the LHS of the =) is not actually an assignment, it's a check. If get_data returned less than N pieces of data, the program would crash (which you can catch and respond to) at that point.
For example, again referencing Erlang since that's the only FP language I'm well-versed in, immutable data + pattern matching means that there are assertions on practically every line of code in production.