Physical Const

An algorithm, procedure, or operations is physically const if it does not alter the physical state (the "bits") of an object or type. This is stronger than LogicalConst; if an operation is physically const it is also logically const.

It is fairly easy for a compiler to enforce PhysicalConstness.

There is a weaker kind of PhysicalConst that doesn't imply LogicalConst; if a const object is allowed to contain pointers to non-const objects, its logical state can change if the physical state of those other objects changes. This form of const isn't much good for reasoning about programs, but it can open the door to some useful optimizations such as object inlining.

Ahhh.... but that's where const gets tricky. If you define the physical state of the object to be shallow (ie, only the bits in my struct, not the bits in objects pointed to by me), what you say is correct. And that's how CeeLanguage and CeePlusPlus operate. On the other hand, if you define physical constness to be deep (all my bits, and all the bits in the transitive closure of all objects pointed to by me), physical constness does indeed imply logical constness. Likewise, if both physical constness and logical constness are shallow (the logical state isn't allowed to include pointed-to objects), then physical constness also implies logical constness.

For practical objects; some referents should be handled deeply and some should be handled shallowly. While what C/C++ does is not ideal, it does work enough of the time to be useful....