Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

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.

> 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.

> 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...

> 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 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...

> 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.

> Please don't get me wrong, I very much appreciate the desire for a 
> comprehensive solution, but at the same time I wonder whether the 
> struggle to integrate three fairly diverse concepts might be part of the 
> reason why this all seems so complicated.  Are they all truly necessary? 

I'd think so.

>  And is it necessary to distinguish all three by separate keywords?

It's not necessary :o).


Andrei