Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Reiner Pope 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.
>>
>> 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?

Yes.

Andrei