Jonathan M Davis Wrote:

> In C++, I tend to declare all local variables const when I know that they aren't going to need to be altered. I'd like to something similar in D. However, D has both const and immutable. I can see clear differences in how const and immutable work with regards to function parameters and member variables, but it's not as clear with regards to const and immutable.
> 
> So, the question is: what are the advantages of one over the other? Specifically, my concern is how likely compiler optimizations are. Does using immutable make compiler optimizations more likely? Or would const do just as well if not better? Or is dmd smart enough that it really doesn't matter if you use const or immutable on local variables which never change?
> 
> - Jonathan M Davis

Doesn't immutability imply static storage? I also thought, it's a way to force CTFE.

On Thu, 18 Nov 2010 14:30:34 -0500, spir <denis.spir@gmail.com> wrote:

> On Thu, 18 Nov 2010 07:50:51 -0500
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote:
>
>> On Wed, 17 Nov 2010 23:41:33 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>> wrote:
>>
>> > In C++, I tend to declare all local variables const when I know that
>> > they aren't
>> > going to need to be altered. I'd like to something similar in D.
>> > However, D has
>> > both const and immutable. I can see clear differences in how const and
>> > immutable
>> > work with regards to function parameters and member variables, but  
>> it's
>> > not as
>> > clear with regards to const and immutable.
>>
>> immutable and const storage classes are identical as far as the compiler
>> is concerned (neither can ever be changed).  However, immutable gives more
>> guarantees as a type modifier.  I'd recommend immutable, because it's a
>> specialization, and while the compiler can know that in a current function
>> a const value is really immutable, it can't pass that knowledge to other
>> functions.
>>
>> For example, a function may be overloaded on both const and immutable
>> because the immutable one can make more assumptions.  If you declare your
>> variable const and call the function with your variable as the parameter,
>> then it calls the const version, even though the data is really
>> immutable.  You lose out on some possible optimizations.
>>
>> Also, pure functions that take immutable can be 'strongly pure' so can be
>> better optimized.
>>
>> All this is moot of course if your variable is a value type :)  But I'd
>> still recommend immutable even in those cases because the definition is
>> clearer -- immutable data can never change, it is assumed that const data
>> can change, but in your case, it will never change.  If nothing else, it
>> conveys the most accurate information to the reader of the code.
>
> Does all the thread finally mean that const is relative to variables, while immutable is (as in FP) relative to elements (be them values or referenced thingies)?

const applied to a value type means the same thing as immutable.  For example:

const int i;
immutable int i;

both say the same thing -- i will never change.

const applied to a *reference* type means that you cannot change that data *through that reference*, but it may change through another reference.

For example:

int i;
const int *j = &i;

I can change i, but not through j.

immutable applied to a reference type means that *nobody* can change that data through any reference.  It is safe to assume it never changes.

For example:

int i;
immutable int j;
immutable int *ip = &i; // Error!
immutable int *jp = &j; // OK

So while immutable and const are basically equivalent on value types (as was the original question), it's more 'correct' IMO to declare them as immutable because of the meaning of immutable -- this will never change, no matter what.

-Steve

On Thursday, November 18, 2010 11:37:51 Kagamin wrote:
> Jonathan M Davis Wrote:
> > In C++, I tend to declare all local variables const when I know that they aren't going to need to be altered. I'd like to something similar in D. However, D has both const and immutable. I can see clear differences in how const and immutable work with regards to function parameters and member variables, but it's not as clear with regards to const and immutable.
> > 
> > So, the question is: what are the advantages of one over the other? Specifically, my concern is how likely compiler optimizations are. Does using immutable make compiler optimizations more likely? Or would const do just as well if not better? Or is dmd smart enough that it really doesn't matter if you use const or immutable on local variables which never change?
> > 
> > - Jonathan M Davis
> 
> Doesn't immutability imply static storage? I also thought, it's a way to force CTFE.

No. If it did, you couldn't initialize immutable stuff at runtime. Apparently, in the case of globals or member variables (which have to be initialized statically anyway), it does mean that they could be optimized out (e.g. there's an open bug report on the fact that immutable fields in structs don't take any space), but that's no the case for local variables which can be initialized at runtime. An enum, on the other hand, _must_ be known at compile-time, and it's not going to take any storage (except for what it puts on the heap if it's a reference type), so enums are the way to declare compile-time constants in D.

- Jonathan M Davis

Jonathan M Davis Wrote:

> > Doesn't immutability imply static storage? I also thought, it's a way to force CTFE.
> 
> No. If it did, you couldn't initialize immutable stuff at runtime. Apparently, in the case of globals or member variables (which have to be initialized statically anyway), it does mean that they could be optimized out (e.g. there's an open bug report on the fact that immutable fields in structs don't take any space), but that's no the case for local variables which can be initialized at runtime.

I see no difference. Both globals and locals can be initialized at runtime and both can be static.

On Saturday 20 November 2010 10:47:27 Kagamin wrote:
> Jonathan M Davis Wrote:
> > > Doesn't immutability imply static storage? I also thought, it's a way to force CTFE.
> > 
> > No. If it did, you couldn't initialize immutable stuff at runtime. Apparently, in the case of globals or member variables (which have to be initialized statically anyway), it does mean that they could be optimized out (e.g. there's an open bug report on the fact that immutable fields in structs don't take any space), but that's no the case for local variables which can be initialized at runtime.
> 
> I see no difference. Both globals and locals can be initialized at runtime and both can be static.

I'm talking about direct initialization. If you do

immutable a = func();

in global scope, func() _must_ be callable at compile-time. If you do that at local scope, it will be done at runtime. If you declare a local variable as static, then it's in the same boat as a global variable because it _is_ a global variable as far as its lifetime goes, just not its scope. However, notice that both

auto a = func();
const a = func();

would have to have func() be callable at compile time if a is a global variable, whereas for a non-static local, it would be done at runtime. In comparison,

enum a = func();

_always_ must have func() be callable at compile-time. immutable says nothing about whether a variable's value must be known at compile time. And CTFE only kicks in when the compiler _must_ do the initialization at compile time.

Also, immutable by itself says nothing about static storage. It either has to be a global variable or be marked with static. And I believe that marking a global variable as static is redundant just like marking a method as public when it is already in a public block is redundant. static in C meant something for global variables, but C doesn't use modules.

- Jonathan M Davis