const again

[Sean Kelly]

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

Oops, one last thing.  Does the transitivity mean it would be impossible 
to have a const array of references to mutable data?


Sean