const again

[Walter Bright]

Sean Kelly wrote:
> Walter Bright wrote:
>> That leaves what to do about manifest constants. It occurs that we 
>> already have a mechanism for them - enums. So why not:
>>     enum x = 3;
>>     enum long y = 4;
>> ? I think that solves our problem.
> 
> One thing that concerns me.  If we assume that "enum x = 3" is simply 
> shorthand for "enum { x = 3 }" then all such declarations would be 
> implicitly typed as integers, which doesn't sound like you want.

It would be implicitly typed to the type of its initializer, or you can 
give a type. Yes, it would behave like a storage class.

>> There's one last problem:
>>     class C { }
>>     const(C)[] a;
>>     a[3] = new C();  // error, x[3] is const
> 
> As I see it, an array of objects can have two levels of const-ness:
> 
> 1. The array itself is const and may not be resized or have its contents 
> changed.
> 2. The array is not const but its elements are, so the array may be 
> resized, but only const member functions may be called on the contained 
> objects.
> 
> To me, "const(C)[]" looks like case 2, because only the element type is 
> in parenthesis.  Thus "const C[]" or "const (C[])" would both represent 
> case 1.  However, this is obviously not how things currently work.

Right, but under the new regime, that is how they would work.

> I 
> this has something to do with the desire to shoehorn tail const into the 
> design, but it doesn't feel natural to me.  Can you explain why it works 
> the way it does?

I've given up on tail const in any of its forms. The new regime has no 
tail const, no head const, it's just const, and fully transitive const 
at that.