On Tue, Jul 10, 2012 at 03:39:30PM -0700, Walter Bright wrote: > On 7/10/2012 3:13 PM, H. S. Teoh wrote: > >I don't think they were rushed. There's been a push for making > >druntime and Phobos const-correct for a while now. I don't think this > >change is a _mistake_ per se, but it does expose a flaw in the > >language: const is too limited in scope, and we need something else > >to fill in for use cases where const isn't good enough. > > > There's a gigantic problem with logical const. It is completely > unenforceable - it is documentation only. All the reasoning and > mechanical guarantees that come with const, immutable, and purity fall > apart. [...]
What about the "partial const" idea I had? Given a class C which derives from a base class B, we may designate the base class B as const, which makes every inherited field const, while C itself may have mutable members. Then we can pass instances of C around as B references (it's OK to implicitly convert C to const(B), because the B part of C is actually const). As far as the user of the B references can tell, the object is const, even though the methods of C may be mutating C-specific members. So C could be a caching class, or whatever it is that needs mutation to work, and B is its "const part" which is guaranteed by the type system never to mutate. T -- Give me some fresh salted fish, please.
