Extended Type Design.

[Don Clugston]

Andrei Alexandrescu (See Website For Email) 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);
>>>
>>> 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.
> 
> Yes.
> 
>> IMHO (b) should be 'readonly' and (c) should be 'const'.
>> But this may be because I'm a physicist, and for me a constant is 
>> something like the speed of light, and C++'s const_cast always seemed 
>> utterly nonsensical.
>>
>> void alabama() {  // Actually compiles! Someone should be shot for this.
>>    const double PI = 3.14159265358;
>>    *const_cast<double *>(&PI) = 4.0;
>> }
>>
>> 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'.
> 
> If we get rid of lazy, I'll sacrifice a lamb :o).
> 
> We've shoved keywords like "readonly" and "view" for a while, and they 
> just added more confusion than cleared, at a high cost. If (as I 
> suspect) super const appears relatively infrequently, it might be fine 
> to just encode it as the mildly verbose "super const". In fact, it's 
> shorter than "keepyourgrubbyhandsoff". :o)
> 
> Andrei

My problem is, I don't see any connection between "don't touch" and 
"constant" except that C++ got them confused. In every other other 
context outside of C++,  "constant" means "it will not change".

Mathematically, you can "hold something constant" (even though it is 
actually a variable), but as long as it is being held constant, it can't 
change.

Suppose in a function, you have 'const' access to a global variable.
Another thread with write-access to that variable can change it, while 
the function is executing.

It makes sense for a function to have read-only access to a variable, 
and need to obtain a mutex when it wants to obtain the current value.
But that's not a constant in any reasonable sense of the word.

Don.