Why D const is annoying

[Mehrdad]

"Chris Cain"  wrote in message news:wyqyigxytaqwwmhfhlej at forum.dlang.org...
> If you want just to specify that (and not ask the compiler to check for 
> you), documentation will do.

Heh, if only the world was so ideal...

> That's _any_ kind of modification of state. If you change state, you can't 
> use immutable/const (nor would you really want to).

Okay...


> D's const/immutable require a different way of thinking of it. What are 
> they useful for? Consider a multithreaded program where some threads 
> depend on information that others have.

I guess this answers my question then: const/immutable are useful for 
multithreading.
So it means, essentially, they're pretty useless for Objects, but only 
useful for structs.
Why? Objects have **behavior** (not just data), and depending on the 
_internal details_ of that behavior would be depending on an implementation 
detail.
Sure, the method writer can call the method 'const', but he really has no 
idea whether someone will override it down the road and get struck by 
lightning because of that.

What D's const seems to be is for *data*, pure and simple (no pun intended).
Using it for behavior would be trying to predict the future implementations, 
and that is pretty damn hard.

Because of that, I think we disallow direct instantiation of const() or 
immutable() Objects altogether, because they're pretty useless.


> In C++, you'd be foolish to not have locks set up even for const variables 
> because they can change at any time for any reason.

Huh? Not if they're instance variables.
It's kind of silly to lock against something so you can modify instance 
variables.

> It's hardly a guarantee and it's so common to violate (look at yourself, 
> for instance) that it means _nothing_.]

I don't think I ever violated C++'s 'const'... (?)

> I liked how it was described as a glorified comment, because that's 
> precisely how I think of it.

More like, a **CHECKED** comment.
Big difference.