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++.
