Stepping back and looking at constness from another angle.

[Lionello Lunesu]

Great post, Jarrett!

I'm having similar feelings towards these new changes. D will get so much 
more complicated, that we really should ask ourselves "is it worth it?".

As for "the problem that const is trying to solve", this reminds me of a 
video I saw from Scott Meyers on Google Video:

http://video.google.com/videoplay?docid=-4728145737208991310&q=red+code

Here's the abstract:
"C++ compilers allow non-const code to call const code, but going the other 
way requires a cast. In this talk, Scott describes an approach he's been 
pursuing to generalize this notion to arbitrary criteria. For example, 
thread-safe code should only call other thread-safe code (unless you 
explicitly permit it on a per-call basis). Ditto for exception-safe code, 
code not "contaminated" by some open source license, or any other constraint 
you choose. The approach is based on template metaprogramming (TMP), and the 
implementation uses the Boost metaprogramming library (Boost.MPL), so 
constraint violations are, wherever possible, detected during compilation."

The idea is, I think, that you'd basically want many compile-time contracts, 
like "const" of "reentrant" or whatever.

(The other use of const is what Bill described: the omnipresent "const 
type&", kind-of like a "inref" or something, but it would be even better if 
the compiler would take care of it.)

L.