Inherited const when you need to mutate

[Andrei Alexandrescu]

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