On 2010-08-12 21:37:11 -0400, Jonathan M Davis <jmdavisp...@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.for...@michelf.com http://michelf.com/
