cannot cast

Jonathan M Davis jmdavisProg at gmx.com
Thu May 3 10:17:32 PDT 2012


On Thursday, May 03, 2012 10:54:47 Namespace wrote:
> On Thursday, 3 May 2012 at 08:46:26 UTC, Chris Cain wrote:
> > On Thursday, 3 May 2012 at 08:00:43 UTC, Namespace wrote:
> >> So, you mean that if i declared any parameter as const, it
> >> have to stay const all the time?
> > 
> > Yes. const = you can't change. Changing it is invalid behavior.
> > Imagine const/immutable as bits in readonly memory and you'll
> > have to right mindset.
> > 
> >> What would you do, if you need in a special case a mutable
> >> version or must change the object itself?
> >> Because there is no "mutable" keyword in D you have to cast
> >> away the constness.
> > 
> > In what way do you mean? If it's something you honestly _need_
> > to change and it's const, then maybe throwing an exception
> > would be appropriate.
> 
> I thought that const = "cannot change directly" and immutable
> stands for "cannot change all the time". If not, why exist both
> storage classes beside?

An immutable variable can never be changed by any reference to that data. It's 
also implicitly shared across threads (since it can never change).

If a const variable is a value type, then there really isn't any difference 
between const and immutable. If it's a reference type, then it just indicates 
that that particular reference cannot alter the data. Another reference may or 
may not be able to (and const is _not_ implicitly shared across threads, 
because the data _can_ change if there are mutable references to it). But if a 
reference is const, it's breaking the type system to cast away const and alter 
the data precisely because the compiler can't know whether that data is 
actually mutable or not. For instance, what if if you did something like

const var = new immutable(A);

var may be const, but it refers to a value which is actually immutable. 
Depending on what the compiler does, mutating var could result in nasty stuff 
like segfaults. In the general case, the compiler has no way of knowing 
whether a const variable is really mutable or immutable underneath. So, 
casting away const and mutating a variable is undefined behavior. As far as the 
compiler is concerned, a variable is _never_ mutated through a const 
reference, and it will optimize code based on that. So, casting away const can 
not only result in segfaults if the data is actually immutable, but it can 
result in incorrect behavior due to optimizations that the compiler makes 
based on the assumption that the variable wouldn't change but which you 
violated by casting away const and mutating the variable.

Unlike immutable, _other_ references to the data may mutate it (and the 
compiler must take that into account when optimizing), but you should never 
try and mutate a const variable. Once something is const, _leave_ it that way. 
If you need a mutable reference to it, then you need to get one which was 
mutable in the first place rather than coming from the const reference through 
casting.

Casting away const is legal, because D is a systems language, but actually 
mutating the variable after casting away const is undefined behavior, so you 
should never do it unless you really know what you're doing.

http://stackoverflow.com/questions/4219600/logical-const-in-d

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list