so what exactly is const supposed to mean?

[Sean Kelly]

Hasan Aljudy wrote:
> Ok, I know that the const issue has apparently been beaten to death on 
> the digitalmars.D NG, but ....
> 
> Can someone please explain to me what does const mean?

That depends.  Typically it means that a reference won't be used to 
mutate referenced data, but that leaves a lot of room for 
interpretation.  C++, for example, uses "logical const" for classes and 
'mutable' qualified members can actually be altered by const member 
functions.  The mutable qualifier is useful in instances where a class 
has members that are more of an implementation detail (a mutex or DB 
connection handle, for example) that may need to be mutated in the 
course of processing const-qualified methods.

 > and doesn't D already have a const keyword?

D has const as a storage attribute, which is a bit different from the 
above.  D's const may only apply to concrete data types, and implies 
that the data will never be modified for the duration of the program. 
This allows the compiler to place such data in ROM and to perform some 
optimizations that would otherwise not be possible.  But this is quite 
limited in that it may only be applied to data that can be evaluated at 
compile-time.

> I think it's something from C++, no? what is it? what does it do? and 
> why do people think it's useful?

Logical const (as in C++) provides a contract ensuring that the user of 
const-qualified data will not modify it in observable ways.  This serves 
to catch accidental errors and to make programmers feel better about 
passing references into unknown code.

> While you're at it, would you mind explaining the implications of 
> implemeting the proposed "const by default" feature?

Again, this depends a lot on how Walter decides to do things, but as 
he's interested in guarantees a compiler can exploit, any form of const 
behavior in D would likely be far stronger than the logical const used 
by C++.  It would likely say more that "this reference will not be used 
to modify its underlying data in any way," similar to how the const 
storage attribute operates.

"const by default" stems from the observation that, in terms of set 
relations, the set of mutable data is actually a subset of the set of 
const data.  ie. of all the data in the world, only some of it will ever 
be altered.  Thus, a typical application would likely have far more 
'const' qualifiers in it to describe programmer intent than it would 
have 'mutable' qualifiers.  Also, it seems far more meaningful to state 
that a particular function *will* alter a particular piece of data than 
that it will not alter the data.

The implication is that references through which mutating operations 
will occur would likely have to be qualified as 'mutable' or 'inout' or 
some such, and that mutating member functions of classes and structs 
would probably have to be labeled as 'mutable' as well.  But I don't 
want to speculate beyond that as I haven't given the issue nearly as 
much thought as Walter has.


Sean