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