Extended Type Design.

[Geoff Carlton]

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
> 
> C++ tries to do all three with one keyword, and makes a confusing hash 
> of it.
> 
> For the purposes of discussion, and to avoid confusing ourselves, we 
> adopted working names of:
> 1) final
> 2) const
> 3) super const
> 

Well, I'm a C++ programmer and I think the last two are much more 
confusing than "readonly" and a different "const".  If they keywords are 
simple and intuitive then the learning curve will be quick.  Can't get 
much better than "readonly" (I can't write to this data, but it may 
change) and "const" (the data will not change).

Consider these two statements:

The problem with C++ "const" is that it isn't really constant.  D fixes 
this by having "readonly" for an immutable view, and "const" actually 
meaning that the data is guaranteed not going to change.

The problem with C++ "const" is that it isn't really constant.  D's 
"const" is also not really constant, but "super const" has been added 
for data that is guaranteed not going to change.

Also, I am slightly confused why examples of final have been given with 
value types:
   final int x = 3;
But x can never be rebound as it isn't a reference - what the user 
really means is the value never changes, therefore keyword (3) rather 
than keyword (1) seems appropriate here.


> The hard part is to figure out how these 3 interact, how they look & 
> feel, how they work with type deduction, type inference, type combining, 
> how do we sidestep the clumsiness in C++'s handling of it, etc.
> 

Regardless of syntax, I would love to hear the advantages of the 
proposed system.  It seems the really big change is the addition of (3), 
but I can't quite see how you could create complex data sets that are 
guaranteed constant apart from using "trust me" casts.

For example, an function may take a data set as super const, therefore 
making optimisations.  But the creation of such a data set (say a map of 
ints to an array of strings, or a graph of nodes) may well be done at 
runtime, such as loading it from a file.  How do you "pin" runtime data 
to get a super constant type?

Can you even create super const data using custom classes?  Must 
everything be done in the constructor?  What about pointers to non-owned 
non-constant data, such as back to an owner object?  I'm intrigued.  Any 
chance of posting some "behind the scenes" with the discussion and 
resolution to the issues you guys have grappled with?