Immutable is a guarantee, that no mutable reference can be obtained on the object from any reference (I don't take into account casting it away, because that's not guaranteed to make the object actually mutable). Const is a guarantee that, no mutable reference can be obtained from this particular reference reference. The key difference is, that const implies the general mutability of the object, which is not accessib Const actually is a logical const. Immutable, on the other hand, is a physical const. I'm not sure if const-defined objects are potentially stored in ROM (in contrast with immutable-defined ones), but if it is, then it shouldn't be, since ROM is purely immutable's domain. Const should in fact be transitive, because if you can change something, you can't change it's part either. Another question is, that casting away const should be 100% defined behavior and result in 100% valid mutable reference, in contrast to immutable. Some classes, for example, may be designed to mutate due to some caching, reference counting or similar mandatory-mutable stuff. In which case the class should be able to obtain a mutable reference on itself. Immutable classes, however should not be able to, because synchronization depends on physical immutability of the data. In light of that, one should be able to define specializations of classes based on their mutability level (kind of class overloading):
class MyCachingClass { /// No const or immutabe shenanigans. /// The class itself is mutable. } const class MyCachingClass { /// Some minor internal tricks with const. /// The class itself is const. } immutable class MyCachingClass { /// No caching, no reference counting. /// The class itself is completely immutable to anyone. } void main() { auto mcc1 = new MyCachingClass; auto mcc2 = new const(MyCachingClass); auto mcc3 = new immutable(MyCachingClass); } The whole point of having const and immutable simultaneously is because const is purely logical and immutable is physical. And const's logic can be changed when necessary, while immutable's cannot. Cheers, Gor. On Thu, Sep 29, 2011 at 12:12 PM, Peter Alexander <peter.alexander...@gmail.com> wrote: > On 29/09/11 8:13 AM, Marco Leise wrote: >> >> Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis <jmdavisp...@gmx.com>: >> >>> On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote: >>>> >>>> For example, storing a reference to a mutex in an object, or a reference >>>> to an owner object. It's the difference between a "has a" relationship >>>> and a "points to" relationship. >>>> >>>> Your lazy loading idea does not help at all for these. >>> >>> I believe that the two main complaints about the lack of logical const >>> which >>> have been coming up in the newsgroup have been the inability to cache the >>> return values of member functions and the inability to lazily load the >>> values of member variables. >> >> I brought the issue with "points to" relationships up in another thread >> here - also about transitive const. I believe a proper object-oriented >> design should allow for pointers to other objects that have nothing in >> common with the host object. car.getVendor() for example should always >> return the mutable instance of the shop where that - possibly const car >> - was bought. Let's call it the "parent reference" issue for short :) >> +1 to Steven's comment. > > Why would a car be able mutate it's vendor? > > Also, the problem with mutable parent references is that it completely > defeats the purpose of const. Consider this C++ code: > > struct Tree > { > Tree* m_parent; > std::vector<Tree> m_children; > > void doSomethingConst() const; > }; > > The tree owns it's children, and has a mutable reference back to its parent. > > Inside doSomethingConst, I shouldn't be able to modify my children because I > own them, however, you are arguing that I should be able to get a mutable > reference to my parent. However, if I can get a mutable reference to my > parent, then I can get mutable references to its children, of which (this) > is one. So, through my parent I can get a mutable reference to myself, > circumventing the const, making it pointless. > > Strict transitive const is essential. Without it, it becomes far too easily > to wriggle your way out of const, which breaks the guarantees of immutable. > >