const again

Sean Kelly sean at f4.ca
Thu Dec 6 14:56:15 PST 2007


Walter Bright wrote:
> 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.

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?  Or would they never want the const 
qualifier to be picked up?  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?

>>> 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.

Oh okay.  Then I'm all for it, at least in theory. :-)

>> 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.

This is unfortunate, but probably for the best.


Sean



More information about the Digitalmars-d mailing list