Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

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

Yes.

> IMHO (b) should be 'readonly' and (c) should be 'const'.
> But this may be because I'm a physicist, and for me a constant is 
> something like the speed of light, and C++'s const_cast always seemed 
> utterly nonsensical.
> 
> void alabama() {  // Actually compiles! Someone should be shot for this.
>    const double PI = 3.14159265358;
>    *const_cast<double *>(&PI) = 4.0;
> }
> 
> 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'.

If we get rid of lazy, I'll sacrifice a lamb :o).

We've shoved keywords like "readonly" and "view" for a while, and they 
just added more confusion than cleared, at a high cost. If (as I 
suspect) super const appears relatively infrequently, it might be fine 
to just encode it as the mildly verbose "super const". In fact, it's 
shorter than "keepyourgrubbyhandsoff". :o)


Andrei