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? and doesn't D already have a const keyword?
I think it's something from C++, no? what is it? what does it do? and why do people think it's useful?

(hmm, I have a feeling that I've asked this before, but can't really remember)

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

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? and doesn't D already have a const keyword?
> I think it's something from C++, no? what is it? what does it do? and why do people think it's useful?
> 
> (hmm, I have a feeling that I've asked this before, but can't really remember)
> 
> While you're at it, would you mind explaining the implications of implemeting the proposed "const by default" feature?

The meaning of const depends on the language it is in. Are you asking about D's const or C++'s const (or other even)?

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

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

Bruno Medeiros wrote:
> 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? and doesn't D already have a const keyword?
>> I think it's something from C++, no? what is it? what does it do? and why do people think it's useful?
>>
>> (hmm, I have a feeling that I've asked this before, but can't really remember)
>>
>> While you're at it, would you mind explaining the implications of implemeting the proposed "const by default" feature?
> 
> 
> The meaning of const depends on the language it is in. Are you asking about D's const or C++'s const (or other even)?
> 

hehe .. well, if I knew I wouldn't ask '^_^

Just the const thing that everyone is talking about.

Sean Kelly wrote:
> 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.

hm, so basically making an object immutable?
Sorry, I didn't get the second part about C++. What do you mean by "logical const"?


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

Is there anything preventing anyone from creating immutable classes?

> 
>> While you're at it, would you mind explaining the implications of implemeting the proposed "const by default" feature?
> [snip] 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.


damn, this doesn't sound too good.
I for one don't give a damn about const, so why should I be bothered to think about the constness of my code/classes and add "mutable" qualifiers all over the place?

Hasan Aljudy wrote:
> 
> damn, this doesn't sound too good.
> I for one don't give a damn about const, so why should I be bothered to
> think about the constness of my code/classes and add "mutable"
> qualifiers all over the place?

Hmm, this sounds bad, for you ... you are aware that immutable objects are your guarantee in multithreaded system to have safe sharing of data? Have you looked at any well designed library in languages like C++, Java or C#? Try to count the immutable classes present, I think you'll find quite a few.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Sean Kelly wrote:
> 
>  > 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.
> 

There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue).

Resummarizing:

D's const has two meanings. The usual meaning is from the form:
  const int var = <some constant initializer>;
and it means that the variable is a compile-time constant and no storage is allocated for it, instead the value is substituted whenever the var is used (like #define, but safer).

The second meaning is from the form:
  const int var; // no initializer
and means that the var must be initialized once in a constructor, and then it becomes non-recursively immutable (meaning you can't change the value of the var, but you can change referenced values). The var has storage and as such is an lvalue.
This is basically the same as final in other languages (Java, C#), and I wonder why it isn't in D as well(?). Walter said he didn't want a const keyword overloaded with many different meanings.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Lars Ivar Igesund wrote:
> Hasan Aljudy wrote:
> 
>>damn, this doesn't sound too good.
>>I for one don't give a damn about const, so why should I be bothered to
>>think about the constness of my code/classes and add "mutable"
>>qualifiers all over the place?
> 
> 
> Hmm, this sounds bad, for you ... you are aware that immutable objects are
> your guarantee in multithreaded system to have safe sharing of data? Have
> you looked at any well designed library in languages like C++, Java or C#?
> Try to count the immutable classes present, I think you'll find quite a
> few. 
> 

Let me repeat:
Is there anything preventing anyone from creating immutable classes?

Hasan Aljudy wrote:

> Lars Ivar Igesund wrote:
>> Hasan Aljudy wrote:
>> 
>>>damn, this doesn't sound too good.
>>>I for one don't give a damn about const, so why should I be bothered to
>>>think about the constness of my code/classes and add "mutable"
>>>qualifiers all over the place?
>> 
>> 
>> Hmm, this sounds bad, for you ... you are aware that immutable objects are your guarantee in multithreaded system to have safe sharing of data? Have you looked at any well designed library in languages like C++, Java or C#? Try to count the immutable classes present, I think you'll find quite a few.
>> 
> 
> Let me repeat:
> Is there anything preventing anyone from creating immutable classes?

Do you see that question at all in your quote above? As it is, it is rather difficult making immutable classes in D, much because the OOP rules in D has deteriorated lately, and the spec has as well. In addition there really is no construct making any useful guarantees about constness, neither for classes nor for code not using classes (which I'm well aware that you abhor).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Bruno Medeiros wrote:
> Sean Kelly wrote:
>>
>>  > 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.
>>
> 
> There is a slight difference from D's const and a const that places the data in ROM as you cannot get the address of a D const var (it's not an lvalue).

Ever tried taking the address of a const string?  That you can't take the address of other const types is simply a result of optimization.

> Resummarizing:
> 
> D's const has two meanings. The usual meaning is from the form:
>   const int var = <some constant initializer>;
> and it means that the variable is a compile-time constant and no storage is allocated for it, instead the value is substituted whenever the var is used (like #define, but safer).
> 
> The second meaning is from the form:
>   const int var; // no initializer
> and means that the var must be initialized once in a constructor, and then it becomes non-recursively immutable (meaning you can't change the value of the var, but you can change referenced values). The var has storage and as such is an lvalue.

Yup.


Sean