Final, Const, Invariant

[Don Clugston]

Walter Bright wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>>> Don Clugston wrote:
>>>> My code has const everywhere. In fact, I use 'const' about ten times 
>>>> as often as 'static' or 'class'. And the new scheme does not seem to 
>>>> have a direct equivalent for it. How can I say, "I want to refer 
>>>> this literal by a name, but in all other respects I want it to 
>>>> behave exactly as a literal"? In particular, I do not want storage 
>>>> associated with it (attempting to take its address is a bug), and it 
>>>> should work with CTFE.
>>>
>>> Replacing const with final should do the trick.
>>
>> Will that prevent taking the address, the same way 'const' does now?
> 
> It's ironic, the "can't take the address of a const" is actually a bug. 
> I guess it has inadvertently turned into a feature! I could argue it 
> either way.

So I've misunderstood the intention of 'const' all this time!
Actually, I don't know how it could work, with the way D does constant 
folding.

Currently, a literal like 3.1f is *not* the nearest value to 3.1 which 
will fit into a float, but rather it's the value 3.1, represented as 
accurately as possible, with a type of 'float'.

const float F1 = float.max * 100.0;
const float F2 = F1/200.0;  // sets F2 = float.max/2.

But if the literal is stored in the executable, it has to be changed 
into 'the nearest value which will fit into a float'. So precision 
drops, and overflow values become infinity.

double D1 = F1; // D1 = float.max*100.0
double D2 = F1/200.0; // D2 = float.max/2.
double X1 = *(&F1); // X1 = infinity
double X2 = *(&F1)/200.0; // X2 = infinity

Which would mean that the same symbol can have a run time value which is 
different to its compile time value.

IMHO, the fact that D currently doesn't allow you to access the run time 
value is a great feature, that is consistent with the constant folding, 
and protects you from subtle bugs.

>> A largely unrelated question, why are existing 'const' items stored in 
>> the obj file (instead of being discarded immediately after use)?
> 
> Because it's a bug that one cannot take the address of them. But it 
> could become a feature, in which case they shouldn't be put in the obj 
> file.

I think it would improve executable size, and possibly compilation time 
as well.