const?? When and why? This is ugly!

[Walter Bright]

If I may restate your case, it is that given function that does 
something with character arrays:

int foo(string s);

and you wish to pass a mutable character array to it. If foo was 
declared as:

int foo(const(char)[] s);

then it would just work. So why is it declared immutable(char)[] when 
that isn't actually necessary?

The answer is to encourage the use of immutable strings. I believe the 
future of programming will tend towards ever more use of immutable data, 
as immutable data:

1. is implicitly sharable between threads
2. is more conducive to static analysis of programs
3. makes it easier for programmers to understand code
4. enables better code generation
5. allows taking a private reference to without needing to make a copy

const(char)[], on the other hand, still leaves us with the temptation to 
make a copy "just in case". If I, as a user, sees:

int foo(const(char)[] s)

what if foo() keeps a private reference to s (which it might if it does 
lazy evaluation)? Now I, as a caller, mutate s[] and muck up foo. So, to 
fix it, I do:

foo(s.dup);    // defensive copy in case foo keeps a reference to s

But the implementor of foo() doesn't know it's getting its own private 
copy, so the first line of foo() is:

int foo(const(char)[] s)
{
     s = s.dup;   // make sure we own a copy
}

so the defensive, robust code has TWO unnecessary copies.