Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Frits van Bommel wrote:
> Don Clugston 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);
> 
> Presumably this can also be an immutable view of immutable (case c) data?

Yes, super const is trivially convertible to const. Const alone really 
means "I don't care about the nature of the data, I just promise I have 
no business writing into it".

>>> 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'.
> [snip]
>> 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'.
> 
> vote++;
> 
> 'const' should really means "constant". A new keyword is more than 
> justified here.

We're doomed either way. We don't want to confuse C++ programmers. Two 
levels of strength of const are more descriptive than a new keyword that 
half of the people will think it's the other way.


Andrei