const again

[Walter Bright]

Sean Kelly wrote:
> I can't say I'm terribly fond of using "enum" for this, but it is 
> certainly closer than any other language feature to what you want. 
> However, I am still questioning the need for a new keyword here.  Is it 
> that the user may sometimes want type inference to pick up the const 
> qualifier and not other times?

Yes for that reason, and the other reason is one rarely wants storage 
allocated for manifest constants. windows.d has 10,000 declarations in 
it, who wants 40K of executable bloat from const declarations?

> Or would they never want the const 
> qualifier to be picked up?

That was my thought, but this has two fatal problems with it:
1) you have to pick up the const qualifier if it's a struct, because the 
struct may wrap a class reference. Thus, structs would not behave like 
the underlying types.
2) Andrei pointed out that C++ (which drops the 'head const') is having 
severe problems with template metaprogramming over this, i.e. it becomes 
impractical to write "forwarder templates".

> If it's the former, then perhaps some rule 
> could be established where the user would never want const to be 
> preserved?  For example, I can't see ever wanting it for basic data 
> types like integers, but I might generally want it for classes.  I 
> suppose what I'm wondering is if this may be one instance where the 
> ideas of head and tail const apply without causing too many problems?

Unfortunately, they do cause problems. For example,
	struct S1 { int x; }
	struct S2 { int* p; :
What does const mean for S1 and S2? Should it be stripped for one and 
not the other?