The Status of Const
Michel Fortin
michel.fortin at michelf.com
Thu Aug 12 18:57:26 PDT 2010
On 2010-08-12 21:37:11 -0400, Jonathan M Davis <jmdavisprog at gmail.com> said:
> 3. The lack of a mutable modifier.
>
> There are times when you need a mutable modifier to sanely use const (it
> obviously wouldn't work with immutable regardless). I don't know if there's any
> way to safely do this with a library or not. It just seems like a deficiency in
> the language itself. As I understand it, Walter thinks that there are serious
> issues with mutable in C++, and I don't know what those are, but I know that
> there are going to be cases where I'd like my code to be const-correct, and I
> won't be able to because there is no mutable in D.
Const-correctness can't work the same in D as in C/C++. Even if you had
a mutable member in your class, D can't allow you to modify this member
from a const member function, because this const member function can be
called when your class is immutable, and if the class is immutable it
can be shared across threads, in which case modifying the member
(without synchronization) would cause races. Basically, D const system
isn't build for const-correctness or to enforce what logically looks
like const, it's built to ease concurrency and sharing of data between
threads. All this to say that when something is const, it *is* const
and it can't cause races.
Perhaps there could be *synchronized* or *shared* islands that could
encapsulate mutable state inside of something immutable -- this would
avoid races -- but I think the addition of such a thing should be
delayed until we get the current system working and we have some
experience with it.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list