Inherited const when you need to mutate

[Jakob Ovrum]

On Tuesday, 10 July 2012 at 21:18:18 UTC, H. S. Teoh wrote:
> If I'm OK with physical const, then all is fine and
> dandy.  But as soon as one thing can't be const, I've to 
> re-engineer my
> entire framework from ground up.
>
> Isn't there something we can do to improve this situation?
>
>
> T

I don't think the answer is to change D's const. D's const, 
unlike C++'s const, only exists to bridge immutable and mutable 
data. As soon as it becomes incompatible with immutable (which 
C++'s const very much is), it ceases to be purposeful.

The problem arises when const is forced upon interfaces like 
toString and opEquals. we don't expect these functions to change 
observable state. In other words, we expect them to be logically 
constant, but not necessarily bitwise constant. That's not 
something the compiler can enforce, and it shouldn't try to. 
Other operators, e.g. opIndex, correctly leave the responsibility 
to the programmer.

There's also the reality that you want toString, opEquals, etc. 
to work with immutable (run-time type) class instances, requiring 
compatibility with const (compile-time type) references.

What I don't understand is why we've chosen const over mutable, 
when we should strive for allowing either and maybe even both. 
We've moved from one end of the scale to the opposite - our 
current situation is equally limiting to the previous situation.

I think these changes were rushed; understandable considering the 
amount of pressure, but it just fixes one problem and creates an 
equally big new problem.