• Kramer (39/39) May 31 2005 What is the difference between final and const in D? I'm only asking in
• Andrew Fedoniouk (33/97) May 31 2005 final and const are different concepts.

Kramer <Kramer_member pathlink.com> writes:

What is the difference between final and const in D?  I'm only asking in
relation to several disscussions on "constness" and comments Matthew, Kris and
others have made.  Since there is no D documentation on final but there is on
const, this is how I'm currently interpreting it.  Please correct me and/or fill
in where I've left a hole or mis-represented, but I'd really like to understand
this issue as it pertains to D.

final:
From Java: "The value of a final variable cannot change after it has been
initialized. Such variables are similar to constants in other programming
languages."
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/finalVariables.html

The above description is how I imagine it's implemented in D.  Sounds a bit like
a constant (be it a variable, method, class, etc...).


const:
Not sure what it means in Java (I don't think it's actually implemented, just a
reserved word), but in D, the docs say "The const attribute declares constants
that can be evaluated at compile time."

The way I read that is, the compiler can do some optimizing to it since it knows
the variable will never change.  But, isn't that what final says as well? (I
could be totally off on the optimizing bit, but hopefully you get my point.)


I certainly don't have a complete understanding on all the technical issues
behind "constness", but I have heard it asked for on this forum and it just
feels like something that should exist in the language.  "constness" kind of
feels like a contract saying that if I pass a variable that I don't want
changed, the compiler should let me know if somewhere in my code, I've violated
that by trying to modify it.  The same goes for if I want to declare a method
parameter as constant; it's a contract saying "I won't change this, but if I
try, please scream at me!".

So maybe there's already a way of doing "constness" in D and maybe that way is
final, maybe it's const.  Maybe it should be the "read-only" keyword I've heard
people mention.  But whatever it is, I believe it should be a keyword of some
sort and not a "best practice" by the programmer.  If it's a keyword, then it's
that much easier to express what you want to say, or rather how the program
should behave.  And after all, isn't that what Contract Programming is about?

-Kramer

P.S. If I've mis-represented anything or anyone, I apologize; and I'm not
trying to beat a dead horse.  I think I must not be getting some obvious answer
that someone has given on this subject, and I'd just really like to fully
understand this concept as it exists in D, as I think it's an important one.

"Andrew Fedoniouk" <news terrainformatica.com> writes:

final and const are different concepts.

'final' means: you cannot change anything final.
You cannot change final value
E.g. you cannot override final class. MyString: String is impossible
in Java. Strings are final there. As char[] and struct in D - you cannot
derive from them.

const in C++ is attribute of type - type modifier and not so restrictive.
const is just an instruction to compiler - warn me if you see an attempt
to change const value.
const is especially useful (and really make sense) for simple (atomic, 
primitive)
types: scalars, arrays and pointers. In classes you can always
do protection of values by wrapping them in getters/setters.
But for e.g. arrays there is no way to say 'I want this array to be
unmutable/nonchageable/const'

Correct me if I am wrong: Internally D runtime has a concept of
constantnes/readonlyness:
e.g. char[] s = "static string";  // s points to memory mapped data section.
s[0] = 'x'; // this assignment should create copy of the string in the heap 
as
it is impossible to write into data section of executable.

I think that it is relatively easy to extend type system of D to support
e.g. arrays and const arrays. - these are just two similar but distinct 
types:

const array has opIndex but not opIndexAssign, has uint length() but
not uint length(uint).

I am not familiar with D compiler internals but from
syntax/grammar point of view I think introduction of const
will not change basics of D. But it will definitely increase
the quality.

Andrew.



"Kramer" <Kramer_member pathlink.com> wrote in message 
news:d7i4co$25vk$1 digitaldaemon.com...
 What is the difference between final and const in D?  I'm only asking in
 relation to several disscussions on "constness" and comments Matthew, Kris 
 and
 others have made.  Since there is no D documentation on final but there is 
 on
 const, this is how I'm currently interpreting it.  Please correct me 
 and/or fill
 in where I've left a hole or mis-represented, but I'd really like to 
 understand
 this issue as it pertains to D.

 final:
 From Java: "The value of a final variable cannot change after it has been
 initialized. Such variables are similar to constants in other programming
 languages."
 http://java.sun.com/docs/books/tutorial/java/nutsandbolts/finalVariables.html

 The above description is how I imagine it's implemented in D.  Sounds a 
 bit like
 a constant (be it a variable, method, class, etc...).


 const:
 Not sure what it means in Java (I don't think it's actually implemented, 
 just a
 reserved word), but in D, the docs say "The const attribute declares 
 constants
 that can be evaluated at compile time."

 The way I read that is, the compiler can do some optimizing to it since it 
 knows
 the variable will never change.  But, isn't that what final says as well? 
 (I
 could be totally off on the optimizing bit, but hopefully you get my 
 point.)


 I certainly don't have a complete understanding on all the technical 
 issues
 behind "constness", but I have heard it asked for on this forum and it 
 just
 feels like something that should exist in the language.  "constness" kind 
 of
 feels like a contract saying that if I pass a variable that I don't want
 changed, the compiler should let me know if somewhere in my code, I've 
 violated
 that by trying to modify it.  The same goes for if I want to declare a 
 method
 parameter as constant; it's a contract saying "I won't change this, but if 
 I
 try, please scream at me!".

 So maybe there's already a way of doing "constness" in D and maybe that 
 way is
 final, maybe it's const.  Maybe it should be the "read-only" keyword I've 
 heard
 people mention.  But whatever it is, I believe it should be a keyword of 
 some
 sort and not a "best practice" by the programmer.  If it's a keyword, then 
 it's
 that much easier to express what you want to say, or rather how the 
 program
 should behave.  And after all, isn't that what Contract Programming is 
 about?

 -Kramer

 P.S. If I've mis-represented anything or anyone, I apologize; and I'm not
 trying to beat a dead horse.  I think I must not be getting some obvious 
 answer
 that someone has given on this subject, and I'd just really like to fully
 understand this concept as it exists in D, as I think it's an important 
 one.