Extended Type Design.

[Reiner Pope]

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

So, would this allow you to express the associative array requirement, that the key must never be changed after it is set?

char[] myKey = "foo";
myAA[myKey] = "bar";
myKey = "something else"; // ERROR: this stuffs up the AA

would you write the getter's signature as superconst?

T set(super const K key) {...}

Is super const allowed as a parameter type?