Extended Type Design.

Walter Bright newshound at digitalmars.com
Fri Mar 16 13:06:55 PDT 2007


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.

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

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.

Once that's all done, picking the right keywords is a whole 'nother 
discussion, with several considerations:
1) common use of 'const' in C++, and the expectations and comfort people 
coming from C++ have with it
2) your point above, that const should be constant
3) keyword minimization
4) avoid stepping on commonly used names
5) ease and economy of typing



More information about the Digitalmars-d mailing list