Extended Type Design ~ don't forget about enum

[kris]

Lars Ivar Igesund wrote:
> Don Clugston wrote:
> 
> 
>>I completely agree with this. The gripe I have is that 'const' is a
>>completely inappropriate term for 'const-as-in-C++'. It's a bizarre
>>misnomer to use 'const' to mean "don't touch". The only benefit (albeit
>>a considerable one) of this nomenclature is compatibility with C++
>>nomenclature, especially the term "const correctness".
>>D currently has a 'const' which actually means "constant", it seems
>>dreadful to exchange that for a clearly inferior "don't touch" meaning.
>>I'm concerned that you may have spent so much time in C++ that you've
>>become accustomed to "const" == "don't touch"; all of my previous posts
>>have been arguing that this is a grossly unnatural association.
>>
>>It is possible that the C++ misnomer is so entrenched that D needs to
>>perpetuate it, even at the expense of breaking all existing D code that
>>uses 'const'.
> 
> 
> I agree with Don here.


So do I

Was somewhat hoping invariant would be used in place of what has now 
taken shape as "const", and "constant" would be used in place of where 
"invariant" has landed. Then there would be no "const" to confuse 
anyone. Almost seems as though shortening the name by a couple of bytes 
is actually more important than the meaning of the words in use?

I'm not sure about "breaking all existing D code" ... there would seem 
to be very little use of "const" at this time, because the current 
semantics are really kinda worthless; e.g. one should probably use enum 
for most things 'constant', except you can't have "enum : char[]" making 
enum notably less useful than it could otherwise be.

Where does enum fit in this picture anyway? Can it recover some duty 
from "const" and/or "final" in a logical and consistent manner?