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