Sorry for silly question, but I have been away from C++ for a long time now. How do these immutable function parameters properties differ from const parameters?
Both const and immutable attributes are transitive, meaning they are "turtles all the way down." People who are used to C and C++'s non-transitive const find it a bit difficult to get used to; people who have used functional languages find it liberating, and it makes for much easier to understand code.
Given that this discussion is already going deep into the implementation level, isn't it possible to flag an object as immutable if it's declared and initialized as a const object, or is a const reference to said const object?
If there was a "imm" keyword in C++ which acted "deeply", that would get us pretty far towards our goal here. However, we'd then find ourselves in cases where we need to (for example) cast from an imm Engine* back to a (non-const) Engine*, often for values returned from functions. That's what this new "region borrow checker" concept would solve.
Interestingly, a transitive immutable data structure can be implicitly converted to transitive const, but not vice versa.
Isn't that already deep within undefined behavior territory?
That hardly is an adequate example, given that it spells an eggregious fault, the kind that's covered by any intro to C++ course with clear indications that it's nonsense.
Immutability is not so simple in C++ as it might first appear.
You have four possible combinations all with different meanings.
It's also why I always I insist on putting const to the right of the declaration part the const is referring too. The C++ standard allows const to the left IF it is the first const. But I think this flexibility is kind of garbage....
Agree about the variable placing being not great. The trouble is most folk use the flexibility to bind the const in the wrong direction, myself included. Then putting it "right" looks "wrong".