Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>> Benji Smith wrote:
>>>>> I should also add that, in my opinion, any design where "const" 
>>>>> means something other than "value resolved at compile time and 
>>>>> immutable at runtime" would be a mistake.
>>>>
>>>> I hear you. I've always disliked C++'s mutable const.
>>>>
>>>> The most important thing at this stage is not the keyword, however, 
>>>> but getting the design right. Andrei, myself and Bartosz have been 
>>>> to hell and back several times over this over the last few months, 
>>>> and have filled about two notebooks with scribblings. It's a 
>>>> difficult problem.
>>>
>>> I very much agree.  But with little information about how these new 
>>> flavors of const will work, it seems we're mostly stuck debating how 
>>> they will look :-)  I'd welcome discussing the former issue, but I 
>>> suspect that anything which is said here will have already been 
>>> discussed between you three.
>>>
>>>> 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;

>>> Further, I don't think I've ever found a need for this particular 
>>> class of immutability in C++.  How often does it really matter 
>>> whether someone can reassign a pointer?
>>
>> Very important. Often you want to bind a pointer to something and make 
>> sure nothing can change that.
> 
> Perhaps this should be rewritten as "often one wants to..."  I just said 
> that I have never felt a need for this :-)  Of the times where I've used 
> this feature in C/C++, I think every single time has been simply out of 
> diligence rather than because there was any risk of the pointer actually 
> being reassigned.  A pertinent point to me is that D uses pass-by-value 
> so the chance of a reference being silently reassigned "somewhere in the 
> program" is typically almost nil.  About the only place where this is a 
> real risk is with global variables, and since free functions support the 
> property syntax, the programmer has a ready option to prevent such a 
> reassignment from happening.  Besides, free globals are bad programming 
> style anyway.

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

>>> As for the other two, it seems like #3 is a storage class
>>
>> No, because the value may embed pointers that you want to pass to 
>> functions. Sorry for sounding dismissive, but we've been all of these 
>> dead alleys for so long, it's all green codes: I can see the damn 
>> Matrix now. Blonde, brunette, const, final...
> 
> That's fine.  You may have been down all these roads before, but I 
> haven't.  I'm mostly asking to gain a better understanding of some of 
> the background.
> 
>>> while #2 is an attribute on the variable itself.  So #3 implies #2.
>>
>> No. #3 implies #2. If a value is super const, then it can be seen as 
>> const. Essentially "const" loses a little of the precision that "super 
>> const" has.
> 
> I'm confused.  I said "so #3 imples #2" and you replied "no, #3 implies 
> #2."  What does the "no" signify?

Sorry, I misread your sentence as #2 implies #3.

>>> I haven't given this much thought, but is it truly necessary to have 
>>> two separate keywords for #2 and #3?
>>
>> It's not! That's what I tried to do all along...
> 
> (see below)
> 
>>> Is this to aid the compiler in optimizing, or is there a perceived 
>>> value here from a user perspective?
>>
>> It will be absolutely essential for the well-definedness of 
>> functional-style threads.
> 
> 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.

>>>  And is it necessary to distinguish all three by separate keywords?
>>
>> It's not necessary :o).
> 
> 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.


Andrei