Constants, Aliases

[Don Clugston]

Lutger wrote:
> Don Clugston wrote:
>> The confusion comes from the way that D uses const in two ways.
>> const XXX = YYY;
>> really is const, cannot be changed (even in theory), and probably 
>> won't appear in the executable at all. This is definitely part of the 
>> type system.
>>
>> const XXX;
>> is not const at all (it's a variable!). 'final' might have been a 
>> better name. As you mention, the read-only protection seems to be very 
>> fragile.
>> It seems a very hard thing to enforce.
> 
> Thank you for the clarification. This means that the original statement 
> from the OP is not true:
> "In D, the standard is to use 'const':
> const int INT = 30;
> The problem with the const keyword is it doesn't guarantee the 
> expression will be constant."

You are correct. The OP statement is untrue.
It's an important distinction -- if it's really a constant, you can use 
it inside a 'static if'. And you're not allowed to take the address of it.

> Then the issue with consts (the first type) in structs and const structs 
> must be a bug?

I think so. There are a few quirks with array literals and apparently 
consts as well -- they look like compile-time constants, but AFAIK they 
are currently implemented as "read-only" variables.

> I was wrong btw about references to members, it only applies to structs 
> not primitives.