Inherited const when you need to mutate

[Timon Gehr]

On 07/11/2012 03:43 AM, Andrei Alexandrescu wrote:
> On 7/10/12 6:39 PM, 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.
>
> I think we need to unlock that mindset lest we risk short-circuiting all
> reason by always (constantly, heh) falling back on dogma a la "logical
> const is unenforceable". This is a very damaging pattern.
>
> We can devise a number of solutions in which there's lazy computation
> inside const methods, while still preserving the current guarantees. The
> only issue with those is they complicate the definition and
> implementation of D.
>
> So the question remains whether the complication is worth it. I
> personally am not convinced. Sure, examples can be found if one looks
> real hard, but I think their importance is overstated when the community
> gets in the mood of proving their need. Fact is, the use of "mutable" in
> C++ is very scant even in codebases that use const religiously (like
> ours). A cursory search yielded 0.01% as many uses of "mutable" as
> "const" in our very large codebase.
>
>
> Andrei

This is unfortunately easily explained using the fact that const is not 
transitive in C++.