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.
