www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - const vs immutable for local variables

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 17 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Nov 17 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 17 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
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=20

 is for runtime. And why would you suggest immutable over const for runtim=


e?

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 diffe=


rence=20

 for a local variable except insofar as a function takes an immutable argu=


ment=20

 rather than a const one. I would think that both would be optimized ident=


ically,=20

 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 =3D 1000000000 ;
	invariant delta =3D 1.0 / n ;

instead of:

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

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

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Nov 18 2010
parent div0 <div0 sourceforge.net> writes:
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
Nov 18 2010
prev sibling parent spir <denis.spir gmail.com> writes:
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 l=
ove it to be the default for the language (or an option to set it so), so t=
hat one would declare local _variables_. Which is never needed, and even sh=
ows 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 =E2=98=A3

spir.wikidot.com
Nov 18 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 18 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
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 wo=


n't=20

 actually be compile time constants. If you use immutable, it'll be create=


d at=20

 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=


=20

 unnecessary local variables get optimized out when they're const or immut=


able.=20

 Do they disappear more as const? or as immutable? Or is it the same for b=


oth?

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

[ . . . ]

=20
 	invariant n =3D 1000000000 ;
 	invariant delta =3D 1.0 / n ;
=20
 instead of:
=20
 	immutable n =3D 1000000000 ;
 	immutable delta =3D 1.0 / n ;





 It used to be that immutable wasn't a keyword. invariant was used. Some f=


olks=20

 complained and Walter added immutable. So, immutable is supposed to be us=


ed for=20

 variables whereas invariant is just for invariants, but it still works to=


 use=20

 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.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Nov 18 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Nov 18 2010
parent reply spir <denis.spir gmail.com> writes:
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=
 =20
 wrote:
=20

 In C++, I tend to declare all local variables const when I know that =20
 they aren't
 going to need to be altered. I'd like to something similar in D. =20
 However, D has
 both const and immutable. I can see clear differences in how const and =




=20

 immutable
 work with regards to function parameters and member variables, but it's=




 =20

 not as
 clear with regards to const and immutable.


=20
 immutable and const storage classes are identical as far as the compiler =


=20

 is concerned (neither can ever be changed).  However, immutable gives mor=


e =20

 guarantees as a type modifier.  I'd recommend immutable, because it's a =


=20

 specialization, and while the compiler can know that in a current functio=


n =20

 a const value is really immutable, it can't pass that knowledge to other =


=20

 functions.
=20
 For example, a function may be overloaded on both const and immutable =20
 because the immutable one can make more assumptions.  If you declare your=


 =20

 variable const and call the function with your variable as the parameter,=


 =20

 then it calls the const version, even though the data is really =20
 immutable.  You lose out on some possible optimizations.
=20
 Also, pure functions that take immutable can be 'strongly pure' so can be=


 =20

 better optimized.
=20
 All this is moot of course if your variable is a value type :)  But I'd =


=20

 still recommend immutable even in those cases because the definition is =


=20

 clearer -- immutable data can never change, it is assumed that const data=


 =20

 can change, but in your case, it will never change.  If nothing else, it =


=20

 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 =E2=98=A3

spir.wikidot.com
Nov 18 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Nov 18 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Nov 18 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 18 2010
parent reply Kagamin <spam here.lot> writes:
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.
Nov 20 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 20 2010