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