Extended Type Design.

[Frits van Bommel]

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bruno Medeiros wrote:
>>> What is the status of the experimental designs for the "storage 
>>> classes" manipulation that Andrei and others where thinking of for D. 
>>> The last I heard from it was Andrei's max suggestion from his max 
>>> design challenge, however, I think that suggestion may suffer from 
>>> some problems in regards to the "maxtype" requirement, plus it is 
>>> wholly incomplete in regards to how storage classes interact between 
>>> each other. Like Andrei said, what is a "const inout lazy const 
>>> char[]", if valid at all? Is there any news here? Is there a 
>>> working(aka complete) design?
>>
>> We have talked about a design. In short, the intent is to define three 
>> flavors of immutability:
>>
>> a) final - a simple storage class controlling the immutability of the 
>> bits allocated for the symbol per se;
>>
>> b) const - type qualifier meaning an immutable view of an otherwise 
>> modifiable data. const does not control the bits of the object, only 
>> the storage addressed indirectly by it (transitively);

Presumably this can also be an immutable view of immutable (case c) data?

>> c) "superconst" - denoted as "const!" or "super const": type qualifier 
>> meaning that the data is genuinely unmodifiable.
> 
> Does this last category include some of the current use of D const -- a 
> value which is not modifiable, *even in theory*, and may not even have 
> any run-time existence at all -- the C equivalent being a #defined 
> constant.
> 
> IMHO (b) should be 'readonly' and (c) should be 'const'.
[snip]
> Whereas 'readonly' seems to be a much better match for (b). Although 
> it's an extra keyword, it seems to me that the concept discussed here is 
> sufficiently fundamental to justify an extra keyword. Especially if we 
> have a chance to rid of 'lazy'.

vote++;

'const' should really means "constant". A new keyword is more than 
justified here.