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.

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