Extended Type Design.

Don Clugston dac at nospam.com.au
Fri Mar 16 00:25:38 PDT 2007


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.

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



More information about the Digitalmars-d mailing list