D const design rationale

[Bruno Medeiros]

Reiner Pope wrote:
> I think that invariant-as-storage-class vs. const-as-storage-class is a 
> false dichotomy, and also that they are incorrectly associated with the 
> completely different type-constructors, const() and invariant().
> 
> 
> As storage classes, const and invariant both mean "compile-time 
> constant" -- their initializers must be evaluatable at compile time, and 
> their data need not be stored in memory.
> 
> However, apparently, data referred to by const-as-storage-class could 
> actually be liable to change (this is cited as the difference between 
> const-as-storage-class and invariant-as-storage-class).
> 
> Yet this seems to clash with the idea of being initialized at compile 
> time: in order for the data pointed to by const-as-storage-class to be 
> changed by another reference, there must be a mutable pointer from which 
> such a variable is initialized. Something like:
> 
> void main() {
>    int a = 10;
>    int* p = &a; // here's our mutable view
>    const int* cp = &a; // here's our const-as-storage-class
> }
> 
> At the moment, this doesn't compile, because &a is not evaluatable at 
> compile time (even though the address of a is statically known). 
> Assuming this is never supported (and I don't think that it should be), 
> then the data pointed to by a const-storage-class variable can never be 
> changed, so the data is really invariant. In that case, 
> const-as-storage-class should be abolished, as it is identical to 
> invariant-as-storage-class.[1]
> 
> ---

I agree. Since in D, compile time values cannot be altered at compile 
time, then any compile time value is immutable/invariant. Thus 
const-as-storage-class is the same as invariant-as-storage-class and 
those concepts should be cleared up.

> 
> I also think that the idea of a "compile time constant" is distinct from 
> invariant-as-type-constructor. For the purposes of clarity, I think it 
> would ideally be better to make this distinction clear, and give this 
> storage class a different name (sorry about Yet Another Keyword). I 
> think 'define' could make sense:
> 
>     define PI = 3.14;
>     define LanguageName = "D Programming Language";
> 
> This also emphasises the similarity in meaning to #define.
> 
> Of course, typeof(LanguageName) == invariant(char[])
> 
> ---
> 

I agree. I don't like this overloading of concepts very much, such that 
'invariant' is used both for compile time values, and invariant data. 
It's quite similiar to 'const' keyword in D 1.0, where it was used both 
for compile time values, and final values.
As for an actual alternative, maybe instead of 'define' we could simply 
use alias:
Either:
   alias PI = 3.14;
or
   alias 3.14 PI;
In any case, using 'alias' that way is actually pretty consistent with 
the current meaning of 'alias'.



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