Inherited const when you need to mutate

[Walter Bright]

On 7/10/2012 4:05 PM, H. S. Teoh wrote:
> 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.

Logical const is still mutating const members.