Stepping back and looking at constness from another angle.

[Ameer Armaly]

"Jarrett Billingsley" <kb3ctd2 at yahoo.com> wrote in message 
news:f428hd$15qa$1 at digitalmars.com...
>I won't lie, I'm not fond of the changes that are being developed.  Now 
>that even my dear, sweet dynamic arrays are having their syntax changed to 
>something like int[new], I figured I'd voice my concerns over it.
>
> I feel (and this coming from someone who has never truly learned 
> const-correctness, this may not mean much) that all the new const stuff is 
> doing is the same thing that C and C++ do.  Yes, there's more granularity 
> by having const, scope, final, and invariant, and even with a new type of 
> unresizeable array.  But it doesn't feel like a D solution for it.
>
> As an example, I'll give the C preprocessor.  D didn't inherit it; 
> instead, it stepped back, looked at what it was used for, and designed the 
> most common features into the language, giving them first-class benefits 
> that the CPP can never give.  We have version statements, debug 
> statements, constants and enums, a proper module system, templates, mixins 
> (templates and string), and soon even AST-based macros, all of which blow 
> the CPP out of the water in terms of parsing and features.
>
> What I'm asking you more seasoned programmers, and those more experienced 
> with const-correctness to do, is to do something similar here.  Step back, 
> and have a look at what constness is for.  What problems does it solve? 
> Is it necessarily the best way to solve them?  More importantly, what 
> problems does it introduce?  Remember, how the language _looks_ is just as 
> important as the features it has.  After all, what do you want to look at 
> for hours on end each day if you use it at your job?
>
> I realize that this is late in the game.  I feel like Walter and company 
> have probably already ironed out most of the issues and semantics of the 
> new syntaxes, if not begun to work on them.  I don't want to discredit all 
> they've done at all.  I'm just wondering if it's the best thing for the 
> language.
>
> (And one final concern is -- what if this is implemented and it's a mess? 
> A total disaster?  Will Walter just say "sorry guys, we messed up" and 
> take it out?  Or will he, having put in so much time and effort, just say 
> "well you're stuck with it"?  This is a huge feature.  This isn't regex 
> match expressions.  If it gets put into the language, it might not be 
> taken back out.  Especially since this is pretty much _the_ D 2.0 
> feature.)
>
Here's an idea that just occured to me:
How about making standalone const mean that whatever the type is it and 
whatever it possibly points to are const and add qualifiers like const(ref) 
and const(data) for use with arrays and classes to point out exactly we want 
to be constant? Here are examples:
1. const char[] c; // pointer and data are const
2. const(ref) char[] c; // the pointer is const but the data is not
3. const(data) char[] c; // the pointer can change, but whatever it points 
to can't be changed
Ideas?