Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

janderson 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
> 
> 
> Thanks for the update:
> 
> BTW:
> 
> const!(char[])
> 
> Looks to much like a template to me, I'd imagine some syntax phasers 
> would have a harder time then necessary.

The damndest thing is that const! (as well as const) _is_ a template: 
it's a type constructor that takes another type as an argument and 
returns a type.

Andrei