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

Jonathan M Davis:

> 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.

In D2 for local variables that don't change use immutable when they are computed at run-time. I'd like to suggest you to use enum when they are known at compile-time, but in some cases this is bad (some examples of associative arrays, etc).


> 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?

Or is dmd dumb enough that it makes no optimization difference? :-)

Bye,
bearophile

On Wednesday 17 November 2010 23:09:40 bearophile wrote:
> Jonathan M Davis:
> > 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.
> 
> In D2 for local variables that don't change use immutable when they are computed at run-time. I'd like to suggest you to use enum when they are known at compile-time, but in some cases this is bad (some examples of associative arrays, etc).

Well. yes. enums are definitely tha case for compile time constants. The question is for runtime. And why would you suggest immutable over const for runtime?

> > 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?
> 
> Or is dmd dumb enough that it makes no optimization difference? :-)

I really don't see any reason why const vs immutable would make any difference for a local variable except insofar as a function takes an immutable argument rather than a const one. I would think that both would be optimized identically, but I don't know.

- Jonathan M Davis

On Wed, 2010-11-17 at 23:21 -0800, Jonathan M Davis wrote: [ . . . ]
> Well. yes. enums are definitely tha case for compile time constants. The question is for runtime. And why would you suggest immutable over const for runtime?

Why use enums rather than immutable for values that are known at compile time?

immutable is really immutable whereas const implies that there is the possibility of change -- at least that is how I read the documentation and TDPL.

[ . . . ]
> I really don't see any reason why const vs immutable would make any difference for a local variable except insofar as a function takes an immutable argument rather than a const one. I would think that both would be optimized identically, but I don't know.

I am a fan of single assignment so I put immutable on all my variables except for loop control variables and accumulators.  I haven't yet seen a need for const.

Interesting, and possibly not irrelevant, side note:  In a moment of complete stupidity I spelled immutable as invariant so had code like:

	invariant n = 1000000000 ;
	invariant delta = 1.0 / n ;

instead of:

	immutable n = 1000000000 ;
	immutable delta = 1.0 / n ;

and it all worked just fine.  I have no idea how or why, but it did!

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday 18 November 2010 00:50:58 Russel Winder wrote:
> On Wed, 2010-11-17 at 23:21 -0800, Jonathan M Davis wrote: [ . . . ]
> 
> > Well. yes. enums are definitely tha case for compile time constants. The question is for runtime. And why would you suggest immutable over const for runtime?
> 
> Why use enums rather than immutable for values that are known at compile time?

enums _must_ known at compile time. immutable variables don't, so they won't actually be compile time constants. If you use immutable, it'll be created at runtime and be less efficient.

> immutable is really immutable whereas const implies that there is the possibility of change -- at least that is how I read the documentation and TDPL.

Sure. You can change const if there are other references to the data which are mutable, but if there aren't then it makes no difference. And when dealing with value types, there really shouldn't be much - if any - difference between const and immutable, because you can't change them in either case.

The real question here is whether there's any real difference in how well unnecessary local variables get optimized out when they're const or immutable. Do they disappear more as const? or as immutable? Or is it the same for both?

> > I really don't see any reason why const vs immutable would make any difference for a local variable except insofar as a function takes an immutable argument rather than a const one. I would think that both would be optimized identically, but I don't know.
> 
> I am a fan of single assignment so I put immutable on all my variables except for loop control variables and accumulators.  I haven't yet seen a need for const.
> 
> Interesting, and possibly not irrelevant, side note:  In a moment of complete stupidity I spelled immutable as invariant so had code like:
> 
> 	invariant n = 1000000000 ;
> 	invariant delta = 1.0 / n ;
> 
> instead of:
> 
> 	immutable n = 1000000000 ;
> 	immutable delta = 1.0 / n ;
> 
> and it all worked just fine.  I have no idea how or why, but it did!

It used to be that immutable wasn't a keyword. invariant was used. Some folks complained and Walter added immutable. So, immutable is supposed to be used for variables whereas invariant is just for invariants, but it still works to use invariant instead of immutable.

- Jonathan M Davis

On Thu, 2010-11-18 at 01:27 -0800, Jonathan M Davis wrote: [ . . . ]
> enums _must_ known at compile time. immutable variables don't, so they won't actually be compile time constants. If you use immutable, it'll be created at runtime and be less efficient.

I guess I am tainted with the C/C++ prejudice that using enums for compile time constants was a hack because they didn't have const.  When const arrived the compiler did all the right things and using enums became bad practice.  The implication of the above is that DMD does not transform immutable values to instruction literals when it can, so using what is now deemed bad practice in C++ is correct idiomatic D?

[ . . . ]
> The real question here is whether there's any real difference in how well unnecessary local variables get optimized out when they're const or immutable. Do they disappear more as const? or as immutable? Or is it the same for both?

I have no idea ;-)  I guess Walter need to comment on this.

[ . . . ]
> > 
> > 	invariant n = 1000000000 ;
> > 	invariant delta = 1.0 / n ;
> > 
> > instead of:
> > 
> > 	immutable n = 1000000000 ;
> > 	immutable delta = 1.0 / n ;

> It used to be that immutable wasn't a keyword. invariant was used. Some folks complained and Walter added immutable. So, immutable is supposed to be used for variables whereas invariant is just for invariants, but it still works to use invariant instead of immutable.

Aha, it wasn't a mistyping, it was a "before a change".  Thanks for pointing the above out, it explains a lot.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thu, 18 Nov 2010 08:50:58 +0000
Russel Winder <russel@russel.org.uk> wrote:

> I am a fan of single assignment so I put immutable on all my variables except for loop control variables and accumulators.  I haven't yet seen a need for const.

For me, this is the default as well, meaning locals are constant. I would love it to be the default for the language (or an option to set it so), so that one would declare local _variables_. Which is never needed, and even shows bad practice, except for symbols assignmed in loops, as you say.
This extends to _value_ parameters, which are just locals as well (in other words, "in" is the default for non-referenced parameters).

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

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.

-Steve

On 18/11/2010 08:50, Russel Winder wrote:
> On Wed, 2010-11-17 at 23:21 -0800, Jonathan M Davis wrote:
> [ . . . ]
>> Well. yes. enums are definitely tha case for compile time constants. The question
>> is for runtime. And why would you suggest immutable over const for runtime?
>
> Why use enums rather than immutable for values that are known at compile
> time?
>
> immutable is really immutable whereas const implies that there is the
> possibility of change -- at least that is how I read the documentation
> and TDPL.
>
> [ . . . ]
>> I really don't see any reason why const vs immutable would make any difference
>> for a local variable except insofar as a function takes an immutable argument
>> rather than a const one. I would think that both would be optimized identically,
>> but I don't know.
>
> I am a fan of single assignment so I put immutable on all my variables
> except for loop control variables and accumulators.  I haven't yet seen
> a need for const.
>
> Interesting, and possibly not irrelevant, side note:  In a moment of
> complete stupidity I spelled immutable as invariant so had code like:
>
> 	invariant n = 1000000000 ;
> 	invariant delta = 1.0 / n ;
>
> instead of:
>
> 	immutable n = 1000000000 ;
> 	immutable delta = 1.0 / n ;
>
> and it all worked just fine.  I have no idea how or why, but it did!
>

invariant is the old deprecated name for immutable.
It'll go away eventually.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

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)?


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com