Extended Type Design.

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>>
>>>>> There are 3 distinct, and very different, flavors of constant:
>>>>>
>>>>> 1) rebinding of a value to a name
>>>>> 2) a read-only view of a data structure
>>>>> 3) a value that never changes
>>>>
>>>> It seems like #1 is only useful for reference types, which currently 
>>>> means pointers and class handles.
>>>
>>> #1 is essential for expressing numeric constants.
>>
>> Could you please provide an example?
> 
> final int x = 42;

I must be missing something here.  I expected this to be the point of 
'const'.  In C++ parlance:

int const * const val = 0;
       ^       ^
       |       |
      #2      #1

> I think "final" is mostly useful in class and struct members.

Seems reasonable I suppose.  Will there be any change to "final" as it 
exists now in D, or is this simply an extension of its meaning?

>> Okay, that's what I figured, though this seems to contradict what you 
>> said above.  So in essence, "super const" is actually necessary in 
>> some situations to indicate to the programmer that the data he is 
>> manipulating is truly immutable.  I almost feel like this feature 
>> should exist separately from the type mechanism, so there was a way to 
>> test for this instead.
> 
> Then you can't prove correctness statically.

Argh.  Good point.

>> So it sounds like it truly isn't necessary to separately distinguish 
>> #2 and #3 via type qualifiers.  Is this correct?  I can appreciate the 
>> need for both, but I very much do not want all of this to become a 
>> confusing mess when applied to actual code.
> 
> Much anything else would become a mess when applied to actual code. I 
> think we discussed about two dozens of schemes. They all looked great on 
> paper, at least at first blush. They all did miserably during a test drive.

Well... darnit :-)


Sean