On 7/10/2012 4:05 PM, H. S. Teoh wrote:
On Tue, Jul 10, 2012 at 03:39:30PM -0700, 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.
[...]
What about the "partial const" idea I had?
Given a class C which derives from a base class B, we may designate the
base class B as const, which makes every inherited field const, while C
itself may have mutable members. Then we can pass instances of C around
as B references (it's OK to implicitly convert C to const(B), because
the B part of C is actually const). As far as the user of the B
references can tell, the object is const, even though the methods of C
may be mutating C-specific members.
So C could be a caching class, or whatever it is that needs mutation to
work, and B is its "const part" which is guaranteed by the type system
never to mutate.
Logical const is still mutating const members.
