Stepping back and looking at constness from another angle.

[Jason House]

Charlie wrote:
> Or the opposite is probably better, make it always error out when the 
> function tries to modify it, and only when you expect it to do the 
> modifying you pass it : foo( mod myInstance );  ( Ignore the syntax, 
> just the idea ).

Honestly, when I first saw in, out, and inout, I thought that was sort 
of the idea... with in being the default.  I considered in to be 
"const&" or "const" depending on efficiency and inout to be "&". 
(Excuse the mixing of C++-like terms).  I liked the simplicity of it. 
Then I discovered that objects are really pointers and the description 
really only applies to the pointer for them.  That's when I had my 
"whoa, this is really wrong" moment.  The lack of const was one of my 
big gripes with the D language.

I'm glad to see that they're working on it.  I'm sad that I don't see 
any documentation on what the new design will (or won't) be. 
Personally, I think "const final scope" seems like a mouthful.  I'll 
never want to type it.  Even typing two keywords seems like a lot to 
me... kind of why I liked the simplicity of in, out, and inout.  If in 
meant what I thought it meant, I probably would have few gripes.

So far, I don't yet have an appreciation for all the complexity of the 
new const system.