const and immutable

Steven Schveighoffer schveiguy at yahoo.com
Tue Jul 6 08:25:23 PDT 2010


On Tue, 06 Jul 2010 10:56:11 -0400, Tim Verweij <tjverweij at gmail.com>  
wrote:

> Hey all,
>
> I'm having some trouble understanding the whole const and immutable of  
> D2,
> especially since it seems documentation is not consistent (Or I'm  
> missing some
> things). I write quite a lot of C++ code btw, so I'm familiar with that.
>
> ---
>
> http://www.digitalmars.com/d/2.0/htomodule.html says: D has const as a  
> storage
> class, not a type modifier. Hence, just drop any const used as a type  
> modifier:
>   void foo(const int *p, char *const q);
> becomes:
>   void foo(int* p, char* q);
>
> http://www.digitalmars.com/d/2.0/const3.html includes D examples like:
>   void foo(const int* x, int* y)
>
> Is the information on the first page not updated for D2?

Yes, the first page is not routinely updated, it looks very outdated.   
consider it a bug of the documentation.  D1 has no const type modifier, D2  
does.

> ---
>
> Is the following correct? (this confuses me)
>
>   immutable int somefunc();
> means the same thing as
>   int somefunc() immutable;
> and not the same thing as
>   immutable(int) somefunc();
> even though the first syntax looks very much like this:
>   immutable int x;

This is a large part of confusion to many users.  It's done this way for  
consistency.  For example, a synchronized method looks like this:

synchronized int foo();

Which does not return a synchronized int, but rather means the function is  
synchronized on this.

In addition, many attributes can be applied in groups via:

attribute
{
    ....
}

or

attribute:
   ....

Similar to protection.  The same goes for const.  So this:

const int somefunc();

and

const {
   int somefunc();
}

are supposed to be equivalent.

People on this NG have petitioned without success to get Walter to remove  
that syntax, or make it mean what it looks like it means.  Code like this:

immutable immutable(int)* foo();

should not be required/allowed :)

>
> ---
>
> I think I understand the difference between const and immuable when
> considering references and pointers, but how exactly is const different  
> from
> immutable in:
> const int x; versus immutable int x;

Functionally, no difference.  Once declared, those cannot be changed.

However, semantically, there is a difference when taking the address:

immutable int x;
const int y;

immutable(int)* yp = &y; // does not compile!
const(int)*xp = &x; // ok, immutable implicitly converts to const.

The thing to remember is that const means you cannot change that value  
through that pointer.  But there is no guarantee that something else is  
able to change the value.

If declaring x to be not changing, the best way to do it is declare it  
immutable, because that is what it is.  Declaring it const means you are  
saying something else might be able to change the value.

> void somefunc(const int x); versus void somefunc(immutable int x);
> const(int) somefunc(); versus immutable(int) somefunc();

These are the same as above.

Note that D enforces transitive const/immutability.  But it also allows  
implicit conversions to any constancy with value types (types without any  
references in them) because simply copying the data completely decouples  
it from the original.

So things like this are possible:

const int x = 5;

int y = x; // ok to copy const to mutable for value types.

But this is not:

int *xp = &x; // error, because there is a reference here!

>
> How does this system interact with in/out/ref etc? Can I for example have
> "const ref int somefunc()"?

Yes.  in/out/ref are all storage classes and can be applied to any type.   
However, you can only use in and out on function parameters, and you can  
only apply ref to function parameters and return values.  You can't  
declare a reference as a local variable like you can in C++.

There is also a type modifier called inout, which is somewhat confusing at  
first but aids greatly in reducing source and gerenated code.  However, it  
is currently very broken.  Eventually, most functions will be inout.

-Steve


More information about the Digitalmars-d-learn mailing list