Extended Type Design.

[Sean Kelly]

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

As for the other two, it seems like #3 is a storage class while #2 is an 
attribute on the variable itself.  So #3 implies #2.  I haven't given 
this much thought, but is it truly necessary to have two separate 
keywords for #2 and #3?  Is this to aid the compiler in optimizing, or 
is there a perceived value here from a user perspective?

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? 
  And is it necessary to distinguish all three by separate keywords?

> C++ tries to do all three with one keyword, and makes a confusing hash 
> of it.

Agreed, despite how the above likely sounds.


Sean