D const design rationale

[Bruno Medeiros]

Daniel Keep wrote:
> 
> Sean Kelly wrote:
>> ...
>>
>> final
>> const
>> final const
>>
>> And that's it.  'final' means a reference cannot be rebound, 'const'
>> means the data cannot be altered (through the reference), and 'final
>> const' means that both the reference is frozen and the data cannot be
>> changed.  And that's it.  That the existence of invariant required the
>> addition of parenthesis on class invariants just serves to strengthen
>> the argument in my mind.  So in short, I'm just not convinced that
>> 'invariant' provides enough utility to warrant the cost in complexity
>> and broken consistency (unittest doesn't require parens, so why does
>> invariant?).
> 
> What makes me uneasy about the above is that final isn't a type
> constructor: it's a storage class.  You're turning it into
> sorta-kinda-but-not-quite both.  So, you end up with:
> 
> final int x;		typeof(x) == int;
> const int y;		typeof(y) == const int;
> final const int z;	typeof(z) == final const int;
> 

And in what are you based to say that those typeofs are like that?
The typeof of each of those 3 vars is int (as reported by DMD). And in 
terms of semantics y and z are exactly the same, only x differs from 
those other two (y and z, are compile-time values, with all that that 
implies).



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