Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

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.

There is talk about deprecating lazy if it's best implemented via other 
mechanisms. There is also talk about deprecating "inout" in favor of 
"ref" on grounds that the often-useful "inout const" is likely to become 
#1 reason for bashing D.

To read a declaration like "const inout lazy const char[]", you can 
first parenthesize it appropriately:

const(inout(lazy(const(char[]))))

The lazy thing is really a delegate that returns a const char[]. The 
inout around it passes that delegate by reference, and the const at the 
top makes the delegate immutable.


Andrei